KYC / KYT Platform

Traditional AML rule engines look at one transaction at a time: "is this transfer over the threshold? does the sender match a watchlist?" This catches the obvious cases and misses the structured ones — layering, smurfing, nested-account funnelling — where each individual transaction looks innocuous but the aggregate pattern doesn't. Graph TM treats every transaction as an edge in a wallet-to-wallet graph; risk scoring runs over the graph topology in addition to per-transaction features. Patterns like "this account funds five accounts that all withdraw within 24 hours to a single beneficiary" are detected as graph subgraphs, not as a thousand independent flagged transactions.

When crypto enters the platform, the KYT layer screens the address and the immediate predecessor history. But the more useful screening is the multi-hop provenance: where did this address get funds from, and where did those upstream addresses get funds, going back N hops? Coreal integrates with Chainalysis and TRM for the heuristic graph and overlays an internal scoring model that weights provenance by recency and depth. A "clean" address that was funded from a known mixer 3 hops back surfaces as elevated-risk; the rule for what to do (block, queue for review, allow with limit) is set by the tenant's policy.

Treating every customer to maximum-friction onboarding (full ID, liveness, address proof, source-of-funds) loses customers who would have been low risk. Treating every customer to minimum friction creates exposure on the riskier ones. Tiered KYC scales depth to risk: tier 1 (telco-verified, low limit) requires identity attestation only; tier 2 (full IBAN, mid limit) adds OCR document + liveness; tier 3 (high limit, crypto) adds source-of-funds, enhanced PEP/sanctions, ongoing monitoring. The policy engine moves a customer up tiers when behaviour or transaction volume requires it, and blocks behaviour that exceeds current tier without step-up.

A pure-ML AML system produces decisions a regulator cannot audit. A pure rule-engine system produces decisions that miss the patterns the rule-writers didn't anticipate. Coreal's scoring is hybrid: a ruleset of explicit checks (sanctions, PEP, threshold-based) runs first, deterministically; an ML scorer runs in parallel for context (peer comparison, behavioural pattern). The rule engine's output is a set of triggered rules with IDs; the ML scorer's output is a score with the top contributing features. A reviewer (and a regulator) can read both in plain English. Decisions never come from the ML score alone.

Suspicious Activity Reports are a regulatory obligation that, in practice, many fintechs treat as an after-the-fact reporting exercise. Coreal's SAR pipeline is a workflow in the BPM engine: cases are opened from TM alerts, an analyst gathers evidence, a reviewer signs off, and the report is generated in regulator-aligned format (goAML XML for FIUs that accept it, structured CSV otherwise). The pipeline tracks SLA from alert to filing; the case archive is searchable by entity, date, typology, jurisdiction. When the regulator audits, the answer to "show me your SAR register for 2026 H1" is one query, not a forensic exercise.