AI compliance layer
The compliance-ai service is the platform's agentic compliance layer. It observes the audit bus, proposes a verdict and a SparseScore explanation on every Gate 3 case, Gate 4 alert, and pre-trade entry, and surfaces those proposals inside the existing Money Laundering Reporting Officer (MLRO) console. This page documents how that service is wired into the rest of the architecture, what authority it does and does not have over customer flows, and how its training and inference are kept inside the platform's data boundary.
1. Why agentic compliance
Three structural properties of regulated on-chain settlement make a rule-based + analyst-only compliance posture a brittle long-run answer. The compliance-ai service is the response.
Signals are sparse and pseudonymous
On-chain transfers, Know Your Business (KYB) on small United Kingdom (UK) companies, and cross-border Ultimate Beneficial Owner (UBO) graphs all carry partial data. Rule engines do not degrade gracefully when an input is absent — they either pass or they don't. SparseScore is built to reason under sparsity and to refuse rather than guess.
Decisions are explainable by construction
MLRO sign-off, Suspicious Activity Report (SAR) filing, and pre-trade compliance all require a written rationale the regulator can read. That makes the decision surface a natural target for an Explainable Artificial Intelligence (XAI) architecture rather than a black-box classifier.
Volume rises faster than headcount
Each new partner tenant multiplies the MLRO queue, the Gate 4 alert stream, and the pre-trade log. Per Financial Conduct Authority (FCA) / Bank of England (BoE) Digital Securities Sandbox (DSS) terms, every secondary trade carries a pre-trade check — that audit cannot stay credible at scale without automation.
2. The compliance-ai service
A thirteenth module in the backend monolith (see backend · module map). Read-only on customer state — it cannot move money, cannot approve a gate, cannot file a SAR. It observes domain events emitted by the other modules, runs the agent, attaches a SparseScore explanation, and proposes a verdict.
Owns
agent_runs, agent_decisions, sparsescore_explanations, training_runs, model_versions, escalations. No customer-facing state.
Listens to
Domain events on the audit bus: SUBJECT_CREATE, GATE_RUN_COMPLETE, MONITORING_ALERT_OPEN, PRE_TRADE_LOG_WRITE, BUYER_REJECT. No direct database reads on customer tables.
Emits
AGENT_PROPOSE_VERDICT with attached rationale + SparseScore explanation. Always written through the audit log; never directly into the kyc, secondary, or compliance services' state.
Trust boundary
Inference runs in-process with the rest of the backend monolith and reads only what the other modules have already written to the database and the audit bus. Training jobs run on dedicated Graphics Processing Unit (GPU) worker nodes outside the production Virtual Private Cloud (VPC); they receive synthetic data only, never production customer data.
Fails closed
If the agent service is unavailable, the MLRO queue continues to operate exactly as it does today — manual decision, manual rationale, rule-based score. No customer flow is gated on the agent's availability.
Versioning
Every agent_decision row records the model_version + policy_version + dataset_signature that produced it. Replay is deterministic given (input, version) — required for regulator reproduction.
Where it plugs into the existing services
3. SparseScore — the explainability engine
SparseScore is the XAI framework that ships inside compliance-ai. It is not bolted on after the fact; the explanation is part of the decision the agent emits.
Input
A bag of signals associated with a subject or a trade. Each signal carries a presence (observed, missing, contradicted) and a weight against the relevant rule set (Money Laundering Regulations 2017 (MLR 2017), Markets in Financial Instruments Directive II (MiFID II), FCA Handbook, on-chain attribution).
Output
A proposed verdict (approve / escalate / decline) plus a structured explanation: the top signals contributing to the score, the regulatory anchor for each, the confidence band, and the counterfactual ("if signal X had been observed, the verdict would have been Y").
Confidence under sparsity
SparseScore is built to refuse rather than guess. When the signal set is too thin to support a high-confidence verdict, the agent emits insufficient_information with the list of missing signals — and that itself is a useful proposal for the MLRO (request the missing evidence).
Anchored to the regulatory rule set
Every signal in the score is mapped to a clause: an MLR 2017 section, a MiFID II classification rule, a Conduct of Business Sourcebook (COBS) principle, a sandbox-specific obligation. Explanations cite the clause. Disconnected "vibes-based" reasoning is rejected at training.
Deterministic replay
Given the same input fingerprint and version triple, SparseScore returns the same explanation. Stored explanations carry the fingerprint so the regulator can independently re-run any historical decision.
Sample budget
An explanation that exceeds the configured token budget is truncated to the top-N signals, with the full payload kept in object storage and referenced by hash on the agent_decisions row.
Worked example · seller onboarding
Coppergate Joinery Limited (Ltd) · FX-APP-77241 · Gate 3 review
Inputs available: Companies House (CH) (active, 12y), Sumsub GREEN on both UBOs, ComplyAdvantage clear, Confirmation of Payee (CoP) matched, low-risk Standard Industrial Classification (SIC), declared customers consistent with credit-report relationships.
SparseScore proposal: approve · confidence 0.91 · model compliance-ai v0.4.2 · policy seller-MLRO-v1.
Top signals (regulatory anchor): company-age 12y (MLR 2017 §28 — proportionate CDD); UBO count 2 of which both verified (MLR §5); SIC code low-risk (Financial Action Task Force (FATF) typologies); CoP matched (PSR direction); ComplyAdvantage clear across UK Treasury / Office of Foreign Assets Control (OFAC) / European Union (EU) / United Nations (UN) (MLR §19).
Counterfactual: if ComplyAdvantage had returned a Politically Exposed Person (PEP) match on either UBO, the verdict would be escalate with rationale "MLR 2017 §35 enhanced due diligence required".
This card surfaces in the MLRO queue alongside Priya Lall's existing decision controls. Priya remains the decision-maker.
5. How the MLRO sees the agent
The agent's outputs surface inside the existing compliance console (compliance.html) — no new tool to learn for Priya's team. The change is two new columns and one new operator view.
MLRO queue · /compliance/mlro-queue
Adds an Agent proposal column showing the agent's verdict pill (approve / escalate / decline) and a confidence band. Clicking the proposal opens the SparseScore explanation panel without leaving the queue.
Submission detail · /compliance/submissions/:id
Adds a SparseScore card next to the existing risk-score card. Shows the top signals, the regulatory anchors, the counterfactual, and a one-click "accept" or "override" against the proposal — both of which require the existing free-text rationale.
Pre-trade audit · /compliance/pre-trade
Adds an Anomaly score column; "filter: anomalies only" already exists and now defers to the agent's score rather than a static heuristic.
Agent decision log · /compliance/ai-decisions
new — needs implementation
A dedicated view for the MLRO to inspect, filter and export every agent decision. Filters: model version, verdict, confidence band, accepted vs overridden. Quarterly export is part of the regulator return.
Agent operator console · /admin/compliance-ai
new — needs implementation
Platform-admin-only. Model version control, dataset signature, deploy & rollback, drift metrics (accepted-vs-overridden rate, confidence calibration), GPU utilisation against the platform's training and inference budget.
Regulator export · /compliance/specification
The existing FCA Sandbox export package gains an AI specification appendix: model card, dataset card, training-run signatures, decision-rate metrics, every model version active in the period. Built into the existing quarterly return.
6. Data, training and inference
Training runs on synthetic data. Customer data does not leave the production VPC. The boundary is hard.
| Data class | Where it lives | What touches it | Retention |
|---|---|---|---|
| Synthetic financial datasets (fraud, identity, Anti-Money Laundering (AML), consumer behaviour) | Training environment · GPU node | Training, evaluation, regression suite | For the life of the model artefact they trained |
| Synthetic shadow traffic (production events with identifiers nulled) | Training environment · isolated from production | Validation against realistic distributions | 90 days rolling |
| Production customer data | Production VPC only · does not leave | Production agent inference only | Existing record-retention policy (5 years standard, 6 for SARs) |
| Model artefacts | FinToken X vault · signed | Production rollout, regulator-facing reproduction | 10 years (sandbox phase) · 6 years steady state |
| Agent decisions + SparseScore explanations | Production database · compliance-ai service | MLRO console, regulator export | Same as audit log — append-only, anchored to the FinToken X Network every 10 minutes |
7. Known limits and how we handle them
Every supervisor will ask: what can the agent get wrong, and what stops a wrong answer from causing harm? Here is the live position.
| Risk | Mitigation in architecture |
|---|---|
Agent proposes approve on a borderline subject the MLRO would have escalated |
MLRO retains the decision; the proposal is one column among many. Override rate is a tracked metric and reviewed by the MLRO monthly. |
| Agent's confidence is mis-calibrated (overconfident on a class with thin training data) | SparseScore is built to refuse rather than guess; insufficient_information is a first-class output. Calibration plots ship with every model release. |
| Drift between training distribution and live distribution post-deployment | Production inference is held behind a canary release and a per-decision drift sentry; drift over threshold pauses inference and reverts to the rule-based score with an MLRO banner. |
| Adversarial input (a subject deliberately structured to game the score) | SparseScore explanations are public to the MLRO — adversarial features show up in the top-signals list. The decision matrix's existing pattern rules (3 buyer rejections in 30d, etc.) still fire. |
| Compute or vendor outage | compliance-ai fails closed — proposals stop arriving in the MLRO queue, the queue keeps working manually. No customer flow is dependent on the agent's availability. |
| The agent's rationale conflicts with the regulator's read of the same evidence | SparseScore's clause-level anchoring is the mechanism that makes the disagreement concrete and resolvable through the platform's standing supervisory channels. |
compliance-aiservice is not a customer-facing surface. Sellers, buyers, lenders, investors, and brokers see no AI surface. The agent's outputs are visible only to the compliance team and the platform admin, inside the existing MLRO console and the operator views described below. The money-control rules in index §5 are not relaxed for the agent — every advisory output is gated on the same human decision that exists today.