Identity Orchestration in finance

Start with the financial product, customer location, accepted documents and applicable identification requirements. Those choices determine whether a journey offers attended video identification, automated document and liveness checks, electronic identification or a supported wallet presentation. Availability depends on the method, market, provider and contracted service.

The IDnow flow documentation describes method selection and conditional branches between verification steps. A provider profile such as WebID helps teams investigate the individual identification service behind a route. The orchestration layer coordinates those services according to the institution's documented policy.

Consider a payment institution designing an account-opening journey for individual customers across several European markets. The following sequence illustrates a possible design, without describing a deployed customer implementation.

1. Collect the application context and explain the requested checks before capturing identity evidence.
2. Offer an accepted electronic identity method where supported, with an approved alternative for other applicants.
3. Check the identity evidence, then send the relevant verified attributes into the screening process.
4. Pause ambiguous matches for an analyst, preserving the reasons and supporting evidence.
5. Request further evidence through an approved route when the original result remains inconclusive.
6. Let the institution assess the complete file before enabling the account and its permitted services.

Each branch needs a named owner, a customer message and a defined outcome. Customers awaiting review need a useful status that acknowledges completed checks and explains the remaining assessment.

Document authenticity and a matching face answer questions about the identity evidence presented. Sanctions screening, politically exposed person checks and the purpose of a relationship address different risks. A successful identity check alone cannot establish that every customer due diligence requirement has been satisfied.

The EBA remote onboarding guidelines address safe customer onboarding within the applicable AML and data protection framework. Teams preparing their control model can examine AMLR and identity verification alongside the operational workflow. Record screening results and review decisions separately enough to explain the final customer decision.

A routing rule can send an inconclusive result into additional checks or a review queue. Map those branches to the documented customer risk and required assurance for the product. Write the reason explicitly, such as unreadable evidence or a potential screening match requiring investigation. Distinguish a correctable capture problem from a result that requires specialist assessment.

Entrust Workflow Studio documentation describes conditional workflows and a manual decision task within an ongoing run. Teams should define who may resolve that task and which evidence they must inspect. Fraud scenarios, including deepfake onboarding attacks, belong in the acceptance tests for those branches.

A retry policy needs limits, clear instructions and a link to the existing application. Customers should understand whether to capture a clearer image, choose another supported method or wait for review. Repeatedly submitting unchanged evidence provides little help to either customers or investigators.

Retry behavior differs between providers, so integrations must preserve those distinctions. The Stripe Identity session lifecycle supports continuing an interrupted verification through the same session. Under the IDnow session model, aborted or expired sessions require creating a new session. Keep the provider session reference linked to the institution's application throughout either path.

Identity results can arrive after the customer has left the verification screen. A completed provider session may also contain a rejected outcome, so completion cannot automatically mean acceptance. The backend must examine the actual outcome before updating the customer application.

The Stripe webhook documentation explains signature verification, duplicate events and delivery without guaranteed ordering. Test those cases before an event can change account status. Verification evidence informs the institution's decision; separate controls determine account access, product eligibility and permission to execute a payment.

A reusable identity route needs a trusted issuer, accepted attributes and evidence that meets the receiving institution's policy. Teams must check freshness and the scope of the presented information before relying on an earlier verification. An existing verification record should remain connected to its source and assessment.

The IDnow orchestration use cases include electronic identity and wallet steps alongside document-based verification. Evaluate actual integration availability before promising customers a particular wallet route. The EUDI Wallet in finance page explains the broader context, while reusable KYC requires its own reliance assessment.

Onboarding establishes evidence about a customer before the financial relationship begins. Later authentication checks whether a returning user can prove the required credentials. A workflow can connect these stages while preserving their separate purposes and decisions.

Teams integrating payments should assess strong customer authentication within the relevant transaction journey. Contract signing also needs its own requirements and evidence chain. A verified identity can support that process, while the selected signature service determines which signature is actually produced.

Explain the requested processing and determine its legal basis before collecting personal information. Consent to a biometric service and the legal basis for required customer checks need separate assessment. Define an alternative route where the relevant legal and product requirements call for one.

The EDPB data protection guide explains purpose limitation, data minimization and retention policies. Agree which evidence the institution keeps, which data providers hold, who can access it and when deletion occurs. An audit record should connect the workflow version, check results and review rationale without indiscriminately copying sensitive identity files into operational logs.

Ask suppliers to demonstrate a supported identity method, an unavailable provider, an interrupted application and a manual review. Include a duplicate webhook and a customer declining biometric processing in the same assessment. Compare the resulting customer messages and audit evidence with the institution's actual operating policy.

Procurement should clarify supported countries and documents, integration ownership, data locations, subcontractors, export options and termination arrangements. Separate platform fees, verification charges and manual review costs when requesting a quote. Measure completion, abandonment, review workload and confirmed fraud together, using comparable populations to assess acceptance changes against the other outcomes.

Identity and access management covers identities, authentication and access rights across applications. Customer Identity Orchestration coordinates checks and decisions within journeys such as financial onboarding. Financial institutions should define which responsibilities belong to each system before choosing an integration.

Automation can execute defined checks and route results through approved rules. Ambiguous evidence and screening matches still need a defined assessment process. The institution must retain responsibility for the customer decision and the controls supporting it.

One provider may cover the methods and markets an institution requires. Additional providers can support specific coverage gaps or approved alternatives during service interruptions. Evaluate their operating complexity and evidence consistency before adding another integration.