Core Concepts
AdvanGuard v2.0 introduces a platform-centered architecture. Here's what you need to know before integrating.
Why a new architecture?
The previous architecture was flow-based: each verification was a standalone session with no data persistence between sessions. This made repeat verifications cumbersome, limited extensibility to new verification scenarios (like AML monitoring), and created friction for clients migrating from platforms like Advangrand.
The new platform-centered architecture solves this with three persistent, reusable entities:
Profile — The user data hub
A Profile is the persistent data record for each end user in your system. Think of it as a long-lived user file that accumulates and retains verified data across multiple verification sessions.
- Created once per end user, referenced via your system's
externalUserId - Stores
fixedInfo(user-submitted data),verifiedInfo(OCR-extracted & confirmed data),idDocs, andriskTags. - Triggers downstream events to AML Monitor, FaceList, and other modules when data changes.
- Enables data re-use: if a user upgrades from Basic KYC to Enhanced KYC, already-verified data is automatically carried forward.
Profile states:
A Profile starts in init when created, and can move through pending, onHold, and completed as verification progresses.
Application — A single verification session
An Application is a single end-to-end verification run. Each Application is linked to exactly one Profile and one Level. It has two phases:
- Submit phase — collecting user data (form submissions, document uploads, selfies)
- Check phase — running automated and manual checks against collected da
When an Application reaches a terminal state, it commits its data back to the Profile.
Application States:
Or it can be terminated at any point: terminated
| State | Description |
|---|---|
init | Collecting user data (Submit phase). The Application Token is active. |
pending | All data collected. Running automated checks (Check phase). |
onHold | Waiting for manual review or external event (e.g. AML alert). |
completed | Terminal state. reviewAnswer is GREEN (pass) or RED (fail). |
terminated | Terminal state. Manually cancelled or timed out. |
Level — A verification template
A Level defines what verification a user must complete. It is a versioned configuration template that specifies which Steps to collect and in what order, and which check nodes to run.
- Each Level has a unique
levelId(e.g.basic-kyc,enhanced-kyc) - Levels are versioned — changes to a Level do not affect in-progress Applications
- Created from a system template (e.g. AML-only, KYC-basic, KYC-enhanced) and customized per client needs
- Different Levels can represent different compliance tiers, jurisdictions, or product lines
Architecture comparison
| Dimension | Previous Architecture | New Architecture (v2.0) |
|---|---|---|
| Data persistence | Each session is independent, no cross-session reuse | Profile persists data across all Applications |
| Flow configuration | Hardcoded flows, new scenarios require custom dev | Level templates, declarative Step orchestration |
| Data re-use | Not supported | Profile pre-fills data, reducing repeat collection |
| Extensibility | Hard to extend to AML, PoA, etc. | Event-driven Profile supports downstream expansion |
Updated 12 days ago