KYC Services Routine

• KYC Identity Validation Routine
• KYC Verification Routine
• KYC Validation Routine against Ecuador
• StartCompareFaces Routine KYC Ecuador

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

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

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

 

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

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.

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

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

 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

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.