Onboarding, KYC, authoritative data, biometrics, evidence and signing.
Channel → proofing/assurance → decision/evidence → bank systems
The technical model separates channel capture, document/eID evidence, PAD/holder binding, authoritative-source checks, policy/assurance and evidence before handoff. CheckID verifies identity within configured scope; it is not represented as the AML or core-banking approval engine without an integration source.
Reverification starts from an existing customer/account context and acquires refreshed evidence or authoritative data according to risk/policy. Results should correlate to the customer reference and are not treated as a new onboarding journey when the business process differs.
Recovery is a high-risk identity event: claimed account → stronger proofing/holder binding → fraud/risk checks → re-binding or exception. Public documentation does not claim CheckID resets credentials or authorizes payments when the bank remains the decision owner.
Identity assurance can provide step-up evidence before a high-risk operation; transaction authorization remains with the bank/payment system unless a contract defines another role.
Assisted flows add an operator, branch/kiosk device and exception handling. Device datasheet capability is kept separate from Mobile-ID-tested compatibility.
Architectural destinations can include mobile/internet banking, branch, CRM, core banking, AML/fraud, IAM, API gateway and SIEM. Public documentation does not imply a direct connector without a source.
The blueprint separates journeys so CTOs can see actors, evidence, sources, exceptions and ownership. Core Banking/CRM/AML/Fraud/SIEM names are reference architecture unless a connector source exists.
| Journey | Identity objective | Key exception | Ownership boundary |
|---|---|---|---|
| Remote onboarding | Prove identity + holder binding + source evidence | Document/source/PAD/match inconclusive | Bank retains account-opening/AML decision |
| Reverification | Refresh identity evidence | Changed/stale data or mismatch | Bank controls customer/account state |
| Account recovery | Re-establish binding before credential recovery | Impersonation/source conflict | Credential reset belongs to Bank/IAM |
| High-risk step-up | Raise assurance for a business event | Insufficient evidence | Transaction authorization belongs to the Bank |
| Branch assisted | Customer + operator + trusted workflow | Operator/device/source exception | Bank operates branch controls |
| Kiosk assisted | Device-mediated proofing | Device/capture failure | Compatibility must be test-evidence-bound |
Mobile/Web/Branch/Kiosk → Bank API/IAM/Integration → CheckID → evidence/biometrics/authoritative sources → decision/evidence → bank systems.
Customer/account identifiers, identity evidence and source-derived attributes have different ownership/purposes; minimization and retention follow contract/policy.
Unavailable source, PAD failure, biometric mismatch, insufficient policy evidence and integration errors remain distinct for retry/manual review/alternate path.
The bank needs correlation among journey, subject/process, source/method and result/evidence; no field is promised beyond the actual contract.
Identity verification supports the bank decision; it does not replace it.
| Journey | CheckID services | Decision boundary |
|---|---|---|
| Remote onboarding | e-Identification + Identity Proofing + e-Verification + holder binding + evidence | Bank owns onboarding/KYC outcome |
| Existing-customer re-verification | e-Verification + authoritative source + step-up | Does not equal account authorisation |
| Account recovery | Identity verification + evidence | Bank owns recovery approval |
| High-risk action | Step-up verification/assurance | Payment/transaction authorisation belongs to bank |
| Branch / assisted | Operator + device + document/eID + biometric | Exception/handoff follows bank process |
| Business customer | Business Verification/KYB + representative | Corporate onboarding/maintenance |
