IDnow

AutoIdent checks identity documents and can combine these checks with selfie comparison and liveness detection, depending on the configured process. VideoIdent instead involves an agent during a live identification session. Electronic identification uses supported digital identity credentials, with German eID providing another route for customers who have the necessary identity document and PIN.

The IDnow developer resources separate these products and their integration documentation. A bank should establish which methods support its document types, customer locations and intended onboarding process before choosing an integration. Language availability, accessibility and an alternative route for unsuccessful attempts also belong in that decision.

IDnow supports API connections and web or mobile integrations for initiating identification and receiving results. In the documented verification flow, a session progresses through technical states, while its outcome records whether verification was accepted or rejected. An aborted or expired session does not provide the same result as a completed assessment.

A completed session can therefore still contain a rejected verification outcome. The onboarding backend should evaluate the outcome and returned evidence before deciding how the application continues. Test cases should include rejection, abandonment, expiry and delayed results, alongside successful identification, so exceptions reach an appropriate review process.

IDnow eSign connects identification with electronic signing, including advanced and qualified electronic signatures. The current API documentation distinguishes product combinations and signature configurations, including identification through VideoIdent or eID. Teams should confirm the enabled method and signature level for their particular implementation before designing the contract journey.

For a lending or payment agreement, identification evidence and signature evidence answer different questions. The institution should decide which documents require a qualified electronic signature, how completed documents return to its systems and how signature failures are handled. Contract validity cannot be inferred from a generic identification success message.

The IDnow orchestration examples combine identity methods with further checks, including address, bank account or AML screening steps. Some documented capabilities have preview labels, making product availability an explicit procurement question. A proposed flow should identify the methods actually contracted and available in each launch market.

Identity orchestration in finance connects those decisions with routing rules, exception handling and operational ownership. A European institution may need different paths for different documents or customer groups, while applying a consistent internal decision policy. Switching methods should retain the relationship between the application, verification attempt and resulting evidence.

The IDnow trust center provides information for reviewing certifications, security and data processing arrangements. Buyers should check the precise product, contracting entity, hosting arrangements and subcontractors covered by the documents they receive. Retention periods, access permissions and evidence exports should match the intended operational process.

Identification is one component of the wider customer due diligence process, alongside the other checks a financial institution must organize. A useful acceptance review covers incomplete evidence, manual escalation and the ability to explain decisions later. The procurement discussion should assign responsibility for each exception and define who makes the final account decision.

IDnow includes wallet and electronic identity methods among its documented orchestration options, with availability depending on the individual capability. Institutions planning EUDI Wallet acceptance in finance should distinguish a supported integration from general production availability across countries. Existing document and video routes remain relevant when a particular customer cannot use the selected wallet method.

A completed session describes technical completion, while the verification outcome can still indicate rejection. Your application should evaluate the returned outcome and evidence before deciding whether onboarding continues.

The choice depends on customer markets, supported documents, process requirements and the institution's own assessment. Compare the exact contracted methods using realistic successful and unsuccessful onboarding cases before choosing your launch configuration.

Identifying an applicant and authorizing a later payment serve different purposes within financial services. Strong customer authentication therefore requires its own design alongside the customer identification process.