Building a Compliance Platform

Each previous post covered a control in isolation. In practice they form one compliance platform — a system where KYC feeds AML, screening runs across both, the audit trail records everything, privacy governs the data, and reporting emits the results. This final post is about engineering that whole: the shared architecture, the cross-cutting concerns, how you test compliance systems, and the practices that make a compliance program genuinely defensible. It assembles the series into a way of building.

The controls are one system

The first thing to see is that the controls are deeply interconnected, not independent modules:

• KYC establishes the customer identity and risk profile → which AML monitoring uses as the baseline for detecting anomalies.
• Sanctions screening runs at onboarding (part of KYC) and on transactions (alongside AML) and continuously as lists update.
• The audit trail records the decisions of every control, uniformly.
• Data privacy governs the personal data all controls collect and process.
• Reporting emits the outputs of monitoring and screening to regulators.

Designed as isolated silos, these controls duplicate data, disagree, and leave gaps (a customer risk score computed one way in KYC and another in AML; screening that doesn’t share results with monitoring). Designed as a platform, they share a common customer/entity model, a unified risk view, shared screening, one audit trail, and consistent data handling. The architectural lesson: build compliance as an integrated platform around shared data and decisions, not as a collection of point solutions — because the controls genuinely depend on each other, and the value (and the gaps) are in the connections.

The cross-cutting concerns

Several requirements from across the series aren’t features of one control but properties the whole platform must have — the through-lines, now as platform architecture:

• Auditability everywhere — every control’s decisions flow into the unified, immutable audit trail (the audit post). This is a platform-wide capability, designed once and used by all controls, not reimplemented per control.
• Explainability everywhere — every automated compliance decision (a flag, a rejection, a match) must be explainable to regulators and affected people (the AML/governance theme). This constrains how the whole platform is built, favoring transparent logic and thorough decision logging across all controls.
• Risk-based throughout — a shared, consistent notion of risk (per customer, transaction, entity) driving graduated scrutiny across KYC, AML, and screening, rather than each control inventing its own.
• Data governance throughout — consistent handling of personal data (privacy, minimization, retention, the erasure/retention reconciliation) across every control that touches it.
• Configurability — regulations change, and differ by jurisdiction, so the platform must let rules, thresholds, and parameters be updated without rewriting code. Compliance requirements are moving targets; a platform hard-coding them is obsolete on the next regulatory change. Externalize the rules.

These cross-cutting properties are what make it a platform rather than a bundle: they’re designed at the system level and inherited by every control, ensuring consistency and closing the gaps that siloed controls create.

Testing compliance systems

A distinctive and under-appreciated engineering challenge: how do you test a compliance system? The stakes make thorough testing essential — a bug in compliance logic isn’t a normal bug, it’s a potential regulatory violation — yet compliance systems are hard to test because they involve detection, judgment, and rare events. Key practices:

• Test against known scenarios — build test cases from known laundering typologies, sanctions-match cases, and edge cases, verifying the system detects what it should (true positives) and clears what it should (true negatives). Your test suite encodes “what must we catch?”
• Test the false-positive/false-negative balance — since these dominate AML and screening (earlier posts), measure detection performance on representative data, and treat changes to detection logic as changes that must be re-validated (a tuning that reduces false positives must not silently raise false negatives).
• Test the audit trail — verify that every decision is recorded completely and immutably, because the audit trail is only trustworthy if it actually captures everything (test that it can’t be bypassed).
• Test data-rights execution — verify that access and erasure actually find and delete all of a person’s data (the privacy post) — a capability that fails silently if untested.
• Test reporting — validate that reports are generated correctly and completely against the required format before they’d ever be filed.
• Regression-test on rule changes — because rules change often, changing them must not break existing detection; a compliance test suite is a regression safety net for a system where regressions are violations.

The mindset: compliance logic deserves more rigorous testing than typical code, because its failures are legal, not just functional. Treat detection rules, data-rights operations, and audit completeness as things with test suites, and re-validate on every change. This connects to the evaluation discipline from the AI and fintech series — you must measure whether the system does what compliance requires, not assume it.

The role of AI, carefully

AI/ML increasingly powers compliance (ML for AML detection and false-positive reduction, verification, screening), and it amplifies both the value and the cautions from across the series:

• The upside — ML catches subtle patterns rules miss and reduces the false-positive burden that overwhelms investigators (the AML post) — genuinely valuable where investigator time is the constraint.
• The non-negotiable caution — explainability. A compliance decision made by a model must still be explainable to regulators and affected individuals; “the model decided” is not an acceptable justification. This is the AI Governance concern applied to a high-stakes regulated context, and it constrains AI use to explainable models or models paired with explanations.
• Human oversight remains — AI assists compliance (prioritizing, detecting, reducing noise), but consequential decisions retain human judgment and accountability. The human-in-the-loop workflows from the AML and screening posts don’t disappear with ML; ML makes them more efficient.

So AI in compliance follows the same rule as elsewhere in this blog: use it for what it’s good at (detection, prioritization, scale), keep it explainable and overseen, and never let it become an unaccountable black box in a domain where you must justify every decision.

The series in one arc

RegTech, end to end: compliance is an engineering discipline, not a legal afterthought (post one), realized as controls — KYC (know who you serve), AML (watch what they do), sanctions screening (block prohibited parties), audit trails (prove it all, immutably), data privacy (protect the data lawfully), and reporting (tell regulators what they require) — that must be built as one integrated platform with auditability, explainability, risk-basis, data governance, and configurability throughout, tested with rigor exceeding ordinary code because its failures are violations, and augmented by AI only where it stays explainable and overseen. Do that, and compliance becomes not a drag on the business but a capability that lets it operate and scale safely in a regulated world — the difference between a company that grows and one that gets shut down.

Key takeaways

• The compliance controls are one interconnected system, not independent modules: KYC feeds AML’s baseline, screening runs across onboarding and transactions, the audit trail records all decisions, privacy governs all data, and reporting emits the outputs — so build an integrated platform around shared data and decisions, not siloed point solutions.
• Cross-cutting properties define the platform: auditability everywhere (one immutable trail), explainability everywhere (every automated decision justifiable), a shared risk-based approach, consistent data governance, and configurability (rules/thresholds updatable without code changes, since regulations change and differ by jurisdiction).
• Compliance systems demand more rigorous testing than ordinary code because failures are legal violations: test against known typologies/edge cases, validate the false-positive/false-negative balance and re-validate on every rule change, and test the audit trail, data-rights execution, and reporting correctness.
• AI amplifies value (catching subtle patterns, cutting false positives where investigator time is the constraint) but must stay explainable (“the model decided” is not a valid justification) and human-overseen for consequential decisions — the AI Governance rule applied to a high-stakes regulated context.
• Compliance engineered as an integrated, auditable, explainable, rigorously-tested platform becomes a capability that lets a regulated business operate and scale safely — not a drag, but the difference between growing and getting shut down.

Further reading

• Regulatory reporting (previous post)
• Compliance as software — start of the series
• AI Governance for Engineers series