Architecture & Innovations
Trust Relay is a KYB/KYC compliance platform for regulated institutions. A compliance officer opens a case; the platform investigates the subject against company registries, sanctions and PEP lists, adverse media and the corporate ownership graph before the customer is asked for anything; the officer then approves, rejects, escalates or requests follow-up inside a durable, fully audited loop.
Two things make it different from a screening tool with a workflow bolted on.
The decision is arithmetic, not a model output. The risk determination is computed by deterministic code from collected evidence. The AI layer gathers and summarises; it does not decide. That is a structural property, not a policy — and it is what makes the decision reproducible and defensible.
It is built for the regulation that is coming, not the one that is leaving. Seventeen AMLR articles already carry an implemented determination. The AMLR reference data is effective-dated to 10 July 2027, and the system deliberately refuses to apply an AMLR value that is not yet in force — it cites the contemporaneous AMLD predecessor instead, and says so. The switchover is already written.
Each capability below states what it gives the team, the obligation it maps to, and whether it is live, staged (built, verified, and deliberately not yet switched on) or partial (capability present, with a stated boundary). Section 8 is the scope section and it is not decorative.
1. What a compliance team gets
| Outcome | How |
|---|---|
| Less work per case | The platform investigates first and only asks the customer for what public sources could not establish. The document request list is derived, not a fixed checklist. |
| Fewer false clears | A check that could not run reports not assessed, never clear. Missing evidence withholds a clean verdict; it never manufactures one. |
| A defensible file, automatically | Every decision carries a mandatory written rationale, the risk factors the officer acknowledged, and an immutable trail. A regulator-ready case pack is one request away. |
| Answers about the law, in the product | Rules cite real articles in an ingested corpus of primary law, and an officer can open the article text from the citation. |
| Continuous coverage, not annual review | Relationships are monitored on statutory cadence ceilings with mandatory event triggers that cannot be configured away. |
| The officer stays in charge | The assistant can raise scrutiny and never lower it. Overrides that reduce scrutiny need a second, different approver. |
2. How a case moves
Investigation comes before the customer is contacted. This is the single biggest change to how the work feels. The platform establishes what it can from public sources, then asks only for the remainder — so the customer receives a short, specific request instead of a standard bundle, and the officer opens a case that is already substantially evidenced.
Documents can raise risk, not only satisfy requirements. Uploaded files are read and scanned for adverse content — criminal or enforcement references, asset freezes, source-of-funds problems, a payment account outside the licensed scope — and feed a risk reassessment. A submitted document pack can move a case to CRITICAL.
Four gates protect the decision. An open beneficial-ownership discrepancy blocks approval. A dissolved entity blocks onboarding unless an audited override is recorded. High-risk approvals route to a second, different approver. And reject or follow-up on a case with a criminal or enforcement predicate is blocked until a signed MLRO suspicious-activity assessment exists — with no officer override, because that boundary is a tipping-off boundary.
3. Built for AMLR — and dated for it
Regulation (EU) 2024/1624 applies from 10 July 2027. AMLA is standing up its supervisory and technical-standards work now. Most platforms will be retrofitted to it. This one encodes it already, with the commencement date in the data.
The effective-dating is the proof. The beneficial-ownership threshold dataset and the
Annex risk-factor dataset both carry effective_date: 2027-07-10. Before that date the
resolver applies the in-force AMLD predecessor and labels the citation as such; it
does not silently apply a rule that is not yet law. Where AMLA has not yet published — the
Art. 51 high-risk sector list — the dataset carries a null effective date and
applies_by_default: false rather than a guessed value.
Articles with an implemented determination
| Article | What the system determines | Status |
|---|---|---|
| 19(1) | Why CDD was triggered on this case, by clause; unevidenced clauses surface as not assessed | live |
| 20(1)(a)–(i) | A nine-measure CDD register — applied, partial, not assessed, or not applicable with a stated reason | live |
| 20(1)(d) | Sanctioned ownership and control: whether sanctioned persons hold >50% or control, individually or collectively, across the multi-path ownership graph | live |
| 20(2)–(3), Annex I/II/III | Which statutory Annex factor each risk driver corresponds to | live |
| 21 | Post-approval relationship lifecycle — suspend, restrict, reinstate, offboard | live |
| 22(1) | Per-actor-type identity dataset, each element marked verified-against-a-register or merely on file | live |
| 22(2), 63 | Exhausted-means record where no natural-person beneficial owner is reached | live |
| 24(1)–(2) | Beneficial-ownership register discrepancy report, 14-day deadline, derogation only where permitted | live |
| 26(2) | Binding cadence ceilings — a tenant cannot configure a looser review interval than the statute allows | live |
| 26(3) | Mandatory event triggers, and the checks that detect them, cannot be switched off | live |
| 26(4) | Immediate re-screen when a new designation is published, not at the next cadence tick | live |
| 52–53 | Beneficial-ownership thresholds, effective-dated, with a category-aware high-risk override | live |
| 54 | Coexistence of ownership and control, as two distinct limbs | live |
| 73 | Tipping-off boundary — customer-facing surfaces default to deny once a SAR predicate exists | live |
| 77 | Five-year retention, with erasure reconciled against it rather than overriding it | live |
| 53(3), 53(4) | Acting-in-concert and nominee arrangements — engine complete; the declared-signal producer is staged off, so this is capability, not coverage | partial |
| 57–61 | Legal arrangements (trusts, foundations) — role-based engine wired; no source decoder emits arrangement data yet | partial |
What this does not claim
There is no transaction-monitoring layer. The system is onboarding and perpetual KYC; transaction surveillance is deliberately out of scope. And AMLR readiness is not certification — what exists is an implemented determination per article with an evidence trail behind it.
4. The assistant: raises scrutiny, never lowers it
An AI assistant is available on seven surfaces, including case detail and the dashboard. It answers questions about a case, drafts a decision memorandum, and reads four AMLR determinations directly — sanctioned ownership, register discrepancies, the senior-managing-official fallback record, and screening currency.
The asymmetry is the design. The assistant can open a discrepancy, flag a gap and escalate. It cannot approve a case, sign a decision, clear an approval gate or resolve a beneficial-ownership discrepancy — those paths refuse it structurally, not by prompt instruction. Its audit-readiness verdict is non-downgradable: a confirmed sanctioned owner or an open register obligation forces BLOCKED, and no favourable assessment can wash it out.
Every chat-driven write requires a named officer and lands in the immutable audit trail. Each surface carries a visible marker that the assistant is assistance, not a determination. Its regulatory answers are grounded in the corpus described next, with citations the officer can open.
5. Rules bound to the text of the law
Most systems carry a citation as a string in a comment. Here a rule is bound to an ingested corpus of primary law, and the binding is checked in two independent ways.
Does the citation resolve? Every citation resolves to one of five states — resolved, instrument-only, non-statutory, not-in-corpus, or unparseable. Five states rather than a boolean, because those failures have different owners. A citation that cannot be verified renders differently to the officer than one that can: the interface fails closed rather than showing an unverifiable reference as though it were sound.
Does the article actually support the rule? This is the harder question and the more valuable one. A separate check reads the cited article's real text against the rule's purpose and returns SUPPORTS, CONTRADICTS, UNSUPPORTED or INDETERMINATE — and indeterminate blocks, because "could not check" must never read as "checked and fine".
That check earns its keep. It caught a rule citing a Dutch AML provision for a PEP obligation where the law had been amended and that paragraph now governs crypto-asset services. The citation still resolved perfectly; the article was simply no longer about the thing. No referential check finds that.
Corpus completeness is itself a named determination: a regulation is recorded as complete, partial or unverified, and a corpus that is missing sections of a law is refused rather than silently accepted at a coverage percentage.
6. A system that learns, under governance
The platform can be taught. An officer's guidance becomes a learned procedure — but a governed one, which is the difference between institutional knowledge and drift.
| Property | Why it matters |
|---|---|
| One active rule per intent, enforced in the database | Five competing rules for one policy cannot accumulate |
| Full lifecycle — draft, active, superseded, deprecated, with lineage | You can see what the guidance used to be and when it changed |
| A learned rule can never suppress scrutiny | A procedure that would reduce checking is refused at save time |
| Learned rules reach the task generator only | They shape follow-up work; they cannot touch the risk arithmetic |
Risk appetite lives in the audited, versioned risk configuration — never in the memory layer. A due-diligence tier is a regulated determination, so the value that sets it is kept where it is versioned, diffable and covered by four-eyes on activation. Activating a configuration that lowers scrutiny — looser appetite, wider thresholds, longer cadence — requires a second, different approver, and the approval is bound to the exact bytes reviewed.
Alongside this, the platform keeps episodic memory of prior investigations so a new case can be informed by similar past ones, and a memory health check that reports the state of the memory layer honestly rather than assuming it is fine.
7. Every decision reconstructable
The question a supervisor asks is: why did you onboard this customer, and can you prove the record has not been edited since?
Why. Every terminal decision carries a written rationale of at least 50 characters, the structured risk factors the officer considered, any conditions imposed, and the regulatory basis. Approval is refused unless every known risk factor has been acknowledged. A conclusion is never overwritten — a correction is an appended amendment with lineage back to what it amends.
Proof. Audit events are immutable at the database, not by convention: a trigger blocks updates and deletes, privileges are revoked, and a foreign key prevents a case from being deleted out from under its own history. Each tenant's events form a hash chain, and anyone with the right can ask the system to replay that chain and name the first break. Every audit row is born on the chain — that this holds for every writer is itself asserted by a test.
On demand. A regulator-ready case pack assembles the full file as a ZIP with a cryptographic manifest, so a recipient can detect alteration. Evidence bundles record what each AI component actually saw. An EU AI Act conformity record is generated from the running system's live model tiers and prompt registry rather than hand-written, and reports each Art. 11–15 obligation as satisfied, partial or a gap.
8. Scope and boundaries
Stated plainly, because a system that is candid about its edges is easier to trust in the middle.
Deliberately not built
- Transaction monitoring. Onboarding and perpetual KYC only.
- Identity proofing (itsme / eIDAS document-and-selfie verification) is a vendor integration that is stubbed and fails closed — it never silently fakes a result. Sanctions, PEP and adverse-media screening are real and live.
Built, deliberately staged off
Several controls are complete, tested and switched off pending calibration review. While staged they do nothing, and this documentation does not describe them as running. The most significant:
| Staged control | What is consequently not happening |
|---|---|
| Reproducible re-derivation of a scoring run from pinned inputs | A past score cannot be replayed from its exact inputs |
| Crypto-shredding for erasure | The decrypt-on-read side is live; no shredding occurs |
Approval refusal on an insufficient_data verdict | The verdict states the truth; it does not yet 409 the approval |
That last row matters and is easy to misread. The verdict is live: a statutory determination that could not run drives the case to insufficient data. What is staged is the control that would refuse the approval on that basis — today it records rather than blocks.
Honest limits of what is claimed
- The audit hash chain proves internal consistency. It is not externally anchored — nothing signs the chain head into an outside store — so it evidences tampering within the system's own custody.
- The Trust Capsule's signature answers "did this deployment seal this?" by certificate pinning. It builds no chain and checks no revocation, and is not an eIDAS qualified signature. Signing is inactive until a signing key and certificate are configured.
- Coverage varies by country. Fourteen jurisdictions have live registry connectors; thirty-two are declared in the capability registry — which exists so the system can say "not assessed for this country" rather than return a confident clear. Knowing what it cannot determine is the point.
Verification
Claims on this page are traceable to the architecture decision records, which are published in full on this site. Flag states were read from the application's own configuration defaults on 2026-09-04, not from prose. Where an ADR's summary is broader than what the code supports, the narrower version is what is stated here.
Screening operates against a corpus of roughly 850,000 sanctioned, wanted and politically-exposed entities, refreshed from source.