Verification target
Claimed data, document/eID data, authoritative attributes, subject-evidence binding and biometric outcomes are used only when the corresponding method is implemented.
CHECKID · VERIFICATION SERVICE
e-Verification
Transactional identity verification with explicit source, method, holder binding, result, evidence and relying-organisation decision boundaries.
SERVICEPurpose → Method → Result
TRUSTSource → Evidence → Scope
OPERATIONSSaaS · API · SDK · SLA
CORE SERVICE
Transactional verification, not a marketing label
Identity claim → method → source → result → evidence
Method
Each verification transaction needs an explicit method; CheckID does not collapse document checks, authoritative lookup and biometric matching into an ambiguous single claim.
Holder binding
Where the transaction must prove that the actor is the holder of the evidence, holder binding can use biometrics/PAD or another supported mechanism according to configuration and source.
Result
Results must distinguish pass/fail/inconclusive/source-unavailable according to the real contract; HTTP success does not by itself mean identity verified.
Evidence
The service output should link transaction, method, provenance, result and evidence references according to the actual data contract.
Decision boundary
CheckID provides identity-verification results; the bank or public service remains responsible for final business decisions such as account opening, payment or authorisation unless a separate contract states otherwise.
FINANCIAL SERVICES
Typical e-Verification journeys
Each journey has distinct triggers, evidence, failure paths and decision boundaries.
| Journey | Input | CheckID role | Exception |
|---|---|---|---|
| Onboarding | New identity/document/eID evidence | Verification before or during identity proofing | Mismatch · source unavailable · step-up required |
| Re-verification | Existing customer | Re-verify when attributes, risk or policy requires it | Stale data · insufficient evidence · holder mismatch |
| Account recovery | Known account/customer | Identity verification supporting the recovery workflow | Does not replace the bank’s authorisation decision |
| High-risk action | High-risk session/action | Step-up verification/assurance where configured | Identity result does not automatically approve the transaction |
INTEGRATION & EVIDENCE
From service intent to API contract
Service → process → result → evidence
CheckID API
Developer documentation exposes subject/process/perform/detail using the current contract; service pages do not rename JSON fields or endpoints for branding.
OpenID Identity Assurance
Where an actual mapping exists, verified claims and verification metadata can represent verified attributes and context; a standards reference does not prove implementation.
Traceable evidence
Evidence is a service output linked to transaction and provenance; fields are called implementation fields only when Tier-1 contract evidence exists.
Privacy
Request and process only data required for the transaction purpose; retention and legal roles depend on the applicable service agreement and approved policy.