This approach is designed to address the gap between Curity's native identity orchestration capabilities and the bank's requirement for end-to-end onboarding flows involving document capture, OCR/eKYC processing, callback handling, customer reconciliation, and risk-based continuation.
Within this model, Curity is not positioned as the OCR engine, the eKYC platform, or the binary file storage system. The OEM layer is also not positioned as the system of record for customer identity evidence. Instead, the OCR/eKYC core platform remains responsible for its own document processing lifecycle, evidence handling, verification logic, and data retention according to the bank's selected vendor architecture. Curity governs the registration journey, authentication-related orchestration, and policy decisions, while the OEM layer bridges the journey between Curity and the external onboarding ecosystem.
The onboarding journey starts when a customer initiates registration from a mobile application or web portal. Curity provides the registration and policy framework for this journey, using its registration flow, signup capabilities, HAAPI-based API-driven flow handling, and authentication orchestration mechanisms. However, instead of expecting Curity to directly manage document lifecycle and complex eKYC service interactions, the onboarding flow is extended through the OEM layer.
The OEM layer acts as the controlled integration layer between the channel, Curity, and the external OCR/eKYC core services. It coordinates the exchange of onboarding context, verification requests, and returned verification results without becoming the long-term storage repository of customer evidence. This allows the onboarding journey to remain policy-driven and centrally controlled by Curity while still supporting richer verification patterns required in banking onboarding.
In practical terms, this means the onboarding architecture separates responsibilities clearly:
In the synchronous model, the customer captures an identity document image through the banking channel. The image is then submitted through the onboarding path to the OCR/eKYC core platform by means of the OEM layer. The OCR/eKYC core platform performs document extraction and returns the extracted attributes in near real time. The OEM layer passes the verification outcome and extracted data back into the Curity-governed registration journey so that the customer can confirm or correct the data before the flow continues.
In this model, Curity remains responsible for orchestrating the onboarding journey and deciding what happens next, but it does not become the document-processing system. The OEM layer also does not need to retain the file as a permanent repository. The raw file and the evidence-processing lifecycle remain under the control of the OCR/eKYC core platform or the bank's designated evidence-handling architecture.
This synchronous model is suitable when the bank requires real-time extraction, immediate user confirmation, and continuation of the onboarding flow in the same session.
In the asynchronous model, the customer still starts the registration journey through Curity, but the OCR/eKYC verification is executed through a delayed processing model. The OCR/eKYC core platform receives the document, performs deeper analysis or longer-running verification, and maintains the verification case and evidence lifecycle within its own domain. The OEM layer coordinates the callback or status update handling and communicates the resulting status, extracted attributes, and verification outcome back into the Curity onboarding journey.
In this pattern, Curity does not need to manage the asynchronous verification lifecycle internally. Instead, Curity maintains the registration journey state and determines how the flow should continue once the external result is available. The OEM layer acts as the controlled bridge for callback handling, state correlation, and policy continuation between the OCR/eKYC domain and the Curity journey.
This asynchronous approach is appropriate when OCR/eKYC processing is more complex, when additional review is needed, or when the bank requires a pending-verification state before final onboarding approval.
For higher-assurance onboarding, the same architectural model can be extended beyond OCR into biometric verification. In this case, the OCR/eKYC core platform or associated external verification engines perform face match and liveness checks using a selfie image or video selfie captured during the onboarding journey. The OEM layer coordinates the exchange between the onboarding channel, the verification engine, and Curity. Curity continues to govern the journey logic and policy decisions, while the actual biometric processing remains in the external verification domain.
This approach allows the bank to support stronger remote onboarding controls without forcing Curity to behave as a face verification engine. It also preserves architectural clarity: Curity governs the onboarding flow, the OEM layer coordinates integration, and the external OCR/eKYC or biometric platform performs specialized verification functions.
A key clarification point is how document images are handled after the client captures and uploads them. In this architecture, neither Curity nor the OEM layer is positioned as the long-term storage repository for customer document files. The banking channel captures the image and submits it through a secure onboarding path. The OEM layer may facilitate the secure submission and transaction correlation required to connect the channel with the OCR/eKYC core platform, but it does not have to store the user's onboarding evidence as a system of record.
Instead, the OCR/eKYC core platform remains responsible for document evidence handling, storage, processing state, verification lifecycle, and retention according to the bank's chosen deployment and compliance model. Curity only needs the extracted attributes, verification status, and reference information necessary to continue the onboarding journey. The OEM layer only needs sufficient transient or correlation data to facilitate orchestration, callback handling, and flow continuation.
This means the architecture can be explained clearly as follows:
This model is often the cleanest way to satisfy both technical and compliance expectations, because it avoids overloading the identity platform with document-storage responsibilities while preserving clear control over onboarding flow decisions.
The OCR/eKYC engine is integrated as an external service, not as a native Curity capability. Curity provides the registration and authentication orchestration framework, while the OEM layer provides the controlled integration path between Curity and the external verification services.
In a synchronous scenario, Curity governs the onboarding step sequence and the OEM layer invokes the OCR/eKYC service, receives the extracted result, and returns the normalized outcome into the Curity journey. In an asynchronous scenario, the OEM layer correlates the onboarding case, receives the callback or polling result from the OCR/eKYC platform, and updates the Curity-governed onboarding process so that the next policy decision can be applied.
This architecture solves the practical gap between Curity's orchestration capabilities and the bank's expectation for full onboarding integration. Curity does not need to directly implement all verification logic itself. Instead, the OEM layer provides the service mediation, normalization, and callback orchestration needed to turn external OCR/eKYC results into controlled onboarding decisions inside the Curity flow.
Curity's role in this model is enabled by the platform capabilities already associated with onboarding and authentication orchestration. HAAPI provides the API-driven journey model required for mobile-native and browserless onboarding flows. Authentication Actions support controlled branching, step sequencing, and insertion of verification-dependent decisions. Signup and registration capabilities support account creation and onboarding attribute collection. JSON/REST integration and scripting provide the mechanisms through which external onboarding results can be incorporated into the Curity-controlled journey.
However, in the proposed architecture, these Curity capabilities should not be interpreted as meaning that Curity directly replaces the OCR/eKYC platform. Instead, they provide the journey framework through which the OEM layer can introduce external verification outcomes into the identity and policy flow. This distinction is important because it keeps Curity aligned with its intended architectural role while still enabling the bank to implement a richer onboarding process.
Once OCR/eKYC processing is completed, the onboarding flow must still continue through reconciliation and identity activation steps. Curity can coordinate the journey so that the returned onboarding data is confirmed by the user, matched against CIF, CRM, or Core Banking records, evaluated against onboarding policy, and then used to create or activate the final digital identity in the User Store or customer account domain.
The OEM layer can also support the normalization and routing of onboarding outputs into these downstream banking systems when needed, without becoming the permanent owner of the data itself. This allows the onboarding model to support:
The result is an enterprise onboarding model in which Curity governs the identity and policy journey, the OEM layer provides onboarding mediation and orchestration support, and the bank's chosen OCR/eKYC and core banking systems remain the authoritative systems for evidence processing and customer master data.
Download the detailed OCR/eKYC integration API reference, including representative onboarding, document upload, verification, callback, and biometric API patterns.
If you are designing a registration and eKYC orchestration layer for a regulated banking environment, Curity can provide the identity core for authentication pipelines, orchestration of external OCR/eKYC services, and secure API integration with the rest of the bank.