Technical entry point for CTOs, CISOs and Chief Architects: system landscape, trust boundaries, security, evidence, deployment and integration.
Technical entry point for CTOs, CISOs and Chief Architects: system landscape, trust boundaries, security, evidence, deployment and integration.
Experience channels reach subject/process orchestration through an integration/API edge; document/eID/biometric/authoritative-source methods produce results, and policy/assurance turns them into decisions/evidence for relying parties.
Separate user/device, customer client, CheckID ingress/core, authoritative/third-party sources, evidence layer and customer enterprise systems, with owner/trust assumptions per boundary.
Subject/process contracts, evidence acquisition, holder binding, policy and results are connected without collapsing authentication or identification into proofing.
Current API authentication is OAuth2 Client Credentials + Bearer. TLS/mTLS, data-at-rest encryption, HSM, tenant isolation and privileged-access claims require separate security evidence.
Correlation uses subject/process/billcode identifiers where the contract exposes them. Integrity and retention mechanisms remain source-bound.
HA/DR/RTO/RPO/scale are NFR/contract values; the architecture center presents models and responsibilities without inventing numbers.
Evidence, holder binding, failure and assurance.
↗Trust boundaries and source-backed controls.
↗Support models, responsibility and contract-bound NFR.
↗Correlation, provenance and audit use cases.
↗REST/Kafka/SDK boundaries from sources.
↗Banking due-diligence view.
↗The Architecture Center separates data flow, control flow and evidence flow so a CTO can see what belongs to the customer channel, CheckID and an authoritative source.
| Boundary | Primary responsibility | Must not be inferred |
|---|---|---|
| User / device | Input capture and user interaction | A device is not automatically an authoritative source. |
| Customer application | Business transaction, customer/account context, authorization | Identity assurance is not payment authorization. |
| CheckID core | Sourced API/process/verification orchestration | Unpublished controls are not asserted. |
| Authority / external source | Source of truth within authorized scope | CheckID does not own authority data. |
| Relying-party backend | Consumes results/evidence and makes business decisions | A CheckID result does not replace the complete RP risk decision. |
Web, mobile, branch and kiosk channels belong to the relying-party experience domain. CheckID is described only through sourced integration contracts.
CheckID API contract V1.2.260123 exposes subject and process. A subject represents the party; a process represents one verification/check. A process result is not the bank or agency account state.
Document/eID, biometrics, authoritative sources and business identity are distinct evidence paths; policy/assurance determines which combination is sufficient.
Verification results, policy decisions, evidence and operational/security logs are distinct artefacts. Correlation uses only identifiers exposed by real sources.
PII, document/chip data, biometric input/derived results, authoritative attributes and evidence metadata are separate classes; retention is stated only from policy/architecture sources.
Invalid input, unavailable source, inconclusive/mismatched evidence, process-state errors and integration failures remain distinct outcomes.
