# KYC Services Routine
Description of the flow of routines available for use by components. Postman
# KYC Identity Validation Routine
The Enrollment routine is intended for users who do not have a previously successful verification record. In operational terms, the flow should start only after `FindByNumberIdSuccess` indicates that there is no successful transaction for the customer. Once that condition is met, the platform creates a new validation transaction, attaches the front and back images of the document, closes the transaction, and retrieves the final outcome through the Validation service.
## Services
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/QbRTl15PRd3EpejF-face-comparison-process-2026-03-24-161224.png)
## How to Communicate Responses
This routine should be communicated at two different levels. The first level is the HTTP result of each individual service call, which confirms whether the technical request was accepted or rejected. The second level is the business outcome obtained from `Validation/{id}`, especially through `Extras.IdState` and `Extras.StateName`. A successful `Close` call does not mean that the business process is complete. The final user-facing outcome should only be communicated after the validation result has been retrieved.
## Response Received
The most relevant technical values in this routine are `Uid`, which links the creation request with the image upload requests and the close request, and `TransactionId`, which identifies the transaction once it has been closed and is later used in the Validation query. The Validation response also provides business-facing fields such as `Extras.IdState`, `Extras.StateName`, `Images`, and `Scores`, which can be used for auditing, compliance, or downstream orchestration.
## Flow Diagram
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/NI4uhaXs1Hv0AdH9-liveness-validation-new-2026-03-26-153503.png)
## Service Invocation
The expected sequence begins with `FindByNumberIdSuccess`. When that service confirms that no successful record exists, the integrator calls `Validation/New` and stores the returned `Uid`. The same `Uid` is then reused in `DocumentFrontSide`, `DocumentBackSide`, and `Close`. Once `Close` returns the `TransactionId`, the integrator queries `Validation/{TransactionId}` until the process reaches a final business state.
## Recommendations
The same `Uid` should be preserved across all intermediate calls. The integration should not assume that the process is complete immediately after `Close`, because the final operational result is determined by the Validation endpoint. Image quality should be monitored closely, since invalid or malformed base64 payloads are a common cause of capture errors. If the project uses OAuth, the token should be obtained before any protected service call and kept valid for the duration of the session.
# KYC Verification Routine
The Customer Verification routine is designed for users who already have a previously successful identity record. The routine should only be triggered after `FindByNumberIdSuccess` returns a successful match for the customer. In this case, the platform performs a new verification against the existing enrolled identity instead of creating a brand-new enrollment flow.
## Services
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/OTRcVj9jxG7tLBSm-face-comparison-process-2026-03-24-174755.png)
How to Communicate Responses
The first communication checkpoint is the result of `FindByNumberIdSuccess`. When that service returns a successful record, the customer is eligible for verification. When it returns `404`, the correct business decision is to use Enrollment instead. The second communication checkpoint is the direct result of `CustomerVerification`, which indicates whether the verification transaction was registered successfully. If the consuming platform requires a consolidated audit trail, the transaction can then be queried through the Validation endpoint.
## Response Received
The most relevant output of this routine is `TransactionId`, which identifies the verification transaction. When a Validation lookup is performed, the response may also include `Extras.IdState`, `Extras.StateName`, and scoring data that can be used for monitoring or compliance review.
## Flow Diagram
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/mE1xBWEpwFVVXKCy-liveness-validation-new-2026-03-26-153611.png)
## Service Invocation
The routine starts with `FindByNumberIdSuccess`. When the result confirms that the customer already has a successful identity record, the platform invokes `CustomerVerification`. If the response contains a transaction identifier, that value can be reused in `Validation/{TransactionId}` whenever a normalized audit response is needed.
## Recommendations
This routine should not be used when the customer does not have a prior successful record. The facial image provided to the verification request should meet the expected quality conditions, and the integration should preserve token validity if OAuth is enabled in the project. Any user-facing conclusion should be aligned with the service outcome and, when needed, with the final Validation response.
# KYC Validation Routine against Ecuador
## How to Communicate Responses
The integration should communicate `Uid` as the technical correlation value across the capture phase, and `TransactionId` as the final reference used to retrieve the result. The business-facing response should be derived from the Validation service rather than from the close request itself, because the Validation response is the authoritative source for the final state of the transaction.
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/DOIAMidEGHRoiDoP-face-comparison-process-2026-03-24-175624.png)
## Response Received
The most relevant technical outputs of this routine are `Uid`, which links all intermediate steps, and `TransactionId`, which identifies the closed transaction. The Validation response can also include functional state information in `Extras.IdState` and `Extras.StateName`, as well as optional evidence such as images and other result details.
## Flow Diagram
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/Z91IstyoV5Ck89nu-liveness-validation-new-2026-03-26-153728.png)
## Service Invocation
The sequence begins with `Validation/New`, which returns the `Uid`. The same identifier is then reused in `DocumentFrontSide`, `DocumentBackSide`, and `CloseRegistro`. Once the transaction is closed, the resulting `TransactionId` is passed to `Validation/{TransactionId}` in order to retrieve the final process outcome.
## Recommendations
The exact path and contract of `CloseRegistro` should be confirmed against the private Swagger before external delivery. The same `Uid` must be preserved during the full capture phase, and the process should not be considered complete until the Validation endpoint returns the final result. Payload quality checks should be enforced for both document images to reduce invalid image or malformed base64 errors.
# StartCompareFaces Routine KYC Ecuador
This routine is designed as a two-step face comparison transaction. The process begins with `StartCompareFaces`, which creates the transaction and returns the `Uid` required to continue the flow. The transaction is then completed with `CloseCompareFaces`, where the final customer face image is submitted together with the same `Uid`. The response of the close service can already contain transaction data and comparison result fields through `BaseValidationDto`.
## Services
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/U5rwXpgVK1uef0DB-liveness-validation-new-2026-03-26-143738.png)
How to Communicate Responses
The integration should communicate `Uid` as the technical correlation value that links the start request to the close request. The final user-facing outcome should be derived from the response returned by `CloseCompareFaces`, since that call completes the routine and can return transaction data and comparison result indicators. If the consuming platform needs additional audit or expanded transaction details, the returned `TransactionId` can later be used in other validation lookup flows already documented in the project.
## Response Received
Both services return data aligned with `BaseValidationDto`. Relevant fields include `Uid`, `TransactionId`, customer identification data, and several face-comparison-specific properties exposed by the Swagger model, such as `ComparationFacesSuccesful`, `ResultComparationFaces`, `ComparationFacesAproved`, `ThresholdCompareDocumentFaces`, and `CompareFacesDocumentResult`. The start request schema is defined by `ApiValidationCompareFaces`, which includes fields such as `ProductId`, `CustomerServicePhoto`, `SignaturePhoto`, `DactilarCode`, `IdentificationNumber`, `Name`, `DocumentType`, `longitude`, `Latitude`, `UrlCallback`, `Gender`, and `BirthDate`. The close request schema is defined by `ApiCloseValidationCompareFaces`, which includes `CustomerPhoto`, `Uid`, and `KeyProcessLiveness`.
## Flow Diagram
[](https://docs.ado-tech.com/uploads/images/gallery/2026-03/FixKKwL844bUnBoU-liveness-validation-new-2026-03-26-144428.png)
## Service Invocation
The integrator starts by calling `StartCompareFaces` and storing the returned `Uid`. That `Uid` must be reused in `CloseCompareFaces`, together with the customer photo and, when applicable, the liveness process key. Once `CloseCompareFaces` returns, the consuming application can evaluate the transaction identifiers and the face comparison result fields included in the response body.
## Recommendations
The same `Uid` must be preserved without modification between the two calls. The implementation should validate the quality of both the service-side source image and the customer photo to reduce `406` responses. If the flow depends on liveness, the `KeyProcessLiveness` should be obtained before the close call and passed exactly as issued by the upstream component. Because the Swagger exposes comparison result fields directly in `BaseValidationDto`, downstream systems should parse those fields explicitly instead of relying only on the HTTP code.