Platform · Module catalog
KYC, KYB, AML and KYT are not products you buy separately here — they are groups of named modules that run inside one journey, in the order you set, with the evidence from each one attached to the same case.
POST /v1/journeys
{
"name": "uae_vasp_retail",
"steps": [
{ "module": "document_verification", "required": true },
{ "module": "passive_liveness", "required": true },
{ "module": "face_match", "threshold": 0.85 },
{ "module": "device_ip" },
{ "module": "sanctions_screening" },
{ "module": "pep_screening" },
{ "module": "adverse_media",
"when": "risk_band in ['medium','high']" },
{ "module": "questionnaire", "id": "source_of_funds",
"when": "risk_band == 'high'" },
{ "module": "ongoing_monitoring", "on": "approved" }
],
"on_flag": "case:edd_queue"
}How composition works
Each module runs independently, returns its own signals, and either passes them to the next step or halts the journey — so a compliance change is a configuration change, not an integration project.
Steps run in sequence with conditions: adverse media only on medium and high risk bands, source-of-funds questionnaire only on high, enhanced due diligence branch on a sanctions hit.
Thresholds, required flags, retry limits, and fallback modules are set per step per journey — retail onboarding and institutional onboarding share modules but not policy.
Every journey change creates a new version, and each decision records the version that produced it, so a case reopened years later still shows the policy of the day. Retention is set to the period your license requires.
Approval is a state, not an end: ongoing AML monitoring, wallet monitoring, and transaction rules keep running against the same customer record.
Every module
Grouped by pillar. Each entry names what the check does, what you send, and what comes back on the decision object.
Prove the person is who they claim to be, that the document is genuine, and that the data on it is usable downstream.
document_verificationAuthenticates an identity document: MRZ parsing and checksums, font and layout comparison against the issuer template, security features, tamper and digital-edit detection, expiry.
nfc_chip_readReads the contactless chip in an e-passport or Emirates ID and validates the issuer's digital signature, so identity data comes from the issuing authority rather than from an image.
data_extractionExtracts name, date of birth, nationality, document number, issue and expiry dates, then normalizes transliteration (including Arabic name handling) so records match across systems.
database_validationConfirms the extracted identity against authoritative and bureau data sources rather than trusting the document alone.
proof_of_addressAccepts a utility bill, bank statement, tenancy contract, or Ejari document, extracts the address, checks document age, and compares it against the declared address.
phone_email_verificationOne-time passcode ownership check plus reputation signals on the number and mailbox (disposable domains, recently created, carrier and line type).
questionnaireCollects the declarations your regulator expects — source of funds, source of wealth, purpose of relationship, expected volumes, tax residency — inside the same session as the identity checks.
Prove the person is physically present and not a replay, a mask, a deepfake, or an account already rejected under another name.
passive_livenessConfirms a live human is in front of the camera from a single capture, with no instructions to follow — defeats printed photos, screen replays, and video injection.
active_livenessChallenge-response capture (movement or on-screen prompts) for high-risk journeys or where a regulator expects an explicit challenge.
face_matchCompares the selfie against the document portrait and returns a similarity score, not a yes/no, so your policy sets the accept, review, and reject thresholds.
face_searchSearches the new face against your own verified population and your blocklist to catch one person opening several accounts under different identities.
biometric_authRe-proves an existing customer at a sensitive moment — large withdrawal, device change, payout address change — by matching against the biometric captured at onboarding.
age_estimationEstimates age from a face capture where a full document check is disproportionate, with document fallback when the estimate lands near the threshold.
device_ipFingerprints the device and inspects the network path: emulator, rooted device, automation, VPN, proxy, hosting ASN, geo mismatch against the claimed residency.
duplicate_blocklistBlocks identities, faces, documents, devices, and wallets you have already rejected, and flags duplicate applications inside the same tenant.
Sanctions, PEP, and adverse-media screening at onboarding, then continuous re-screening for the life of the relationship.
sanctions_screeningScreens the verified identity against sanctions and terrorist-designation lists, with fuzzy matching tuned for Arabic transliteration variants and name ordering.
pep_screeningIdentifies politically exposed persons, their relatives, and close associates, with the exposure category and role recorded so enhanced due diligence can be justified.
adverse_mediaSearches negative news mapped to predicate offence categories, so a hit arrives as a reason code your analyst can act on rather than a wall of articles.
ongoing_monitoringRe-screens every monitored customer on a schedule for the life of the relationship, and fires a webhook the day a new listing, PEP designation, or adverse-media hit appears.
match_resolutionStructured false-positive handling: an analyst discounts a match with a documented reason, and the same match will not resurface unresolved on the next screen.
Registry truth, ownership structure, controlling persons, and the same screening applied to every human behind the entity.
registry_lookupPulls the entity record from its registry: legal name, license number, status, incorporation date, registered address, activity.
ownership_graphWalks the shareholding chain through intermediate holding entities, calculates effective ownership percentages, and identifies beneficial owners against your threshold.
controlling_personsExtracts directors, authorized signatories, and persons exercising control, then queues each of them for individual KYC and screening.
entity_screeningScreens the company itself — and every owner and controller found — against sanctions, PEP, and adverse media, including ownership-based sanctions exposure.
kyb_documentsRequests, receives, and classifies trade license, memorandum, board resolution, register of members, and proof of registered address, with expiry tracking and renewal reminders.
Post-onboarding risk: rule-based transaction monitoring, on-chain wallet exposure, and Travel Rule counterparty data.
transaction_monitoringRuns your rule set over each transaction in real time or in batch: velocity, structuring, threshold avoidance, unusual corridors, dormancy reactivation, peer-group deviation.
wallet_screeningScores a crypto address before you pay out or credit a deposit: sanctioned address exposure, darknet, mixer, scam, and high-risk exchange exposure, direct and indirect.
transaction_tracingTraces funds back through hops to the originating cluster and forward to the destination, giving the analyst the picture rather than a lone score.
travel_ruleExchanges originator and beneficiary information with counterparty institutions on qualifying transfers, and records what was sent, received, or refused.
counterparty_vasp_discoveryAttributes a destination address to an institution and resolves whether a Travel Rule message can be delivered to it, or whether the destination is an unhosted wallet.
travel_rule_scopeDecides whether a transfer is in scope before any personal data leaves your tenant, using the threshold and transfer rules of the applicable regime.
unhosted_wallet_proofCollects proof that a self-custody destination belongs to your customer: signed message, declaration, or in-session verification, retained as an artefact.
ongoing_wallet_monitoringWatches previously cleared addresses and raises an alert when a wallet becomes sanctioned or gains exposure after you approved it.
The surfaces around the checks: journey builder, case management, reporting, evidence export, and the audit trail.
journey_builderComposes modules into an ordered journey with branching: run this check only if that one flags, escalate to enhanced due diligence on a risk band, skip a step for a low-risk segment.
risk_engineWeighted, explainable scoring across every signal produced in the journey. Each score shows the contributing factors and the policy version that produced it.
case_managementAlert queues, assignment, four-eyes approval, escalation paths, notes, and a full decision history for every customer and every alert.
reportingAssembles the case narrative, evidence, and decision history into the workpaper an analyst files with the relevant financial intelligence unit.
audit_trailAppend-only record of every check, decision, override, policy change, and export — who, what, when, and under which policy version.
evidence_exportProduces a decision PDF or evidence bundle per case, and bulk exports to your warehouse or object storage for inspection and retention.
A 30-minute walkthrough with a compliance engineer, or a sandbox key in your inbox today.