Compliance by Design vs Bolt-On: The Doctrine AML Borrowed

Every scaling business hits the same moment. Growth outpaces the compliance function, a regulator sends a letter, and the reflex is to add headcount and another vendor. Compliance, in this telling, is a team you hire and a tool you buy.

It is not. Financial-crime compliance breaks not because a team is too small, but because the controls were bolted onto a platform after it was built. That is the question behind compliance by design vs bolt on, settled first by the security profession: compliance is an architecture you design, and the discipline that names it — secure by design — comes from cybersecurity.

"Secure by Design": The Doctrine Financial Crime Is Borrowing

Cybersecurity spent two decades learning that security cannot be an afterthought. In October 2023, CISA — with the FBI, NSA and partners — published Shifting the Balance of Cybersecurity Risk, urging software manufacturers to ship products secure by design rather than adding security after release. Its principles rebuke bolt on security and make developers own security outcomes early, so customers inherit fewer evolving threats. NIST's Secure Software Development Framework (SSDF, SP 800-218, February 2022) codified the same secure by design move, building security across the software development lifecycle — the SDLC — with standards that reduce vulnerabilities in the code before penetration testing.

Firewalls added late or security features bolted onto a finished product do not produce secure code. Built-in security does. Security is not a feature you add; it is a property you design in. The remedy is resilience built in by design, not reactive patching — with standards making developers responsible for security in the code they ship. Bolt on security fails because the vulnerabilities are structural, and no later testing recovers the code already shipped or the vulnerabilities it carries. A secure by design product ships with software security embedded, carrying fewer potential threats and security risks.

"Security by design" is not merely a slogan. GDPR Article 25 — data protection by design and by default (Regulation (EU) 2016/679, adopted 27 April 2016) — makes it a statutory requirement to build safeguards into processing, confirmed by the EDPB's Guidelines 4/2019. The by-design principle carries legal force, and the same secure by design logic decides whether financial-crime controls survive scale and evolving threats — a principle, not a set of policies stapled on.

From secure software to systems that carry their own evidence

In cybersecurity the designed-in property is the resistance a secure system is built for against the threats it faces; in financial crime it is verifiable evidence. A control that cannot produce proof is the AML equivalent of software whose security was retrofitted, its vulnerabilities exposed under testing — the security principle embedded in the attestation, the secure path this analysis traces into AML and KYC.

You Cannot Buy Compliance

Bolt on compliance is compliance added as headcount and stacked tooling after a platform has scaled — teams bolt on controls once the business has already grown. Compliance by design is evidence, lineage and verifiability decided at the design stage. The security question is architectural: whether the controls produce effective outcomes, not the size of the team. In practice this is the secure by design test — is a control a security property built into the systems, or a security layer added late to meet a regulatory requirement?

The Binance and OKX enforcement pattern

Two enforcement actions show controls failing as volume grew. Binance pleaded guilty on 21 November 2023 in a resolution exceeding $4.3 billion; the Department of Justice found it "did not implement comprehensive know-your-customer (KYC) protocols or systematically monitor transactions." FinCEN's $3.4 billion penalty found "categorical gaps," users exempted from KYC requirements, and a control regime that arrived late. OKX pleaded guilty on 24 February 2025 to an unlicensed money-transmitting business and $505 million in penalties, with employees advising customers to falsify KYC information.

These were not under-resourced teams; they were businesses whose controls were circumvented as the business scaled past what they could carry. At its peak, Binance ran a high-risk retail derivatives business at global scale; the product outgrew a compliance architecture it never matched — the design was an afterthought, the same security lesson these organisations learned elsewhere.

From tick-box technical compliance to effectiveness

Regulators moved the goalposts from paper compliance to outcomes. FATF's 2022 methodology assesses technical compliance and effectiveness — "with the emphasis of any assessment on effectiveness" — requiring a working framework, not paper. FinCEN's AML/CFT Programme NPRM (7 April 2026, Federal Register 10 April 2026) would replace a technical-compliance model with an effectiveness-based, risk-driven framework anchored to a documented risk assessment. The FCA's Dear CEO letter of March 2024 named it: "business growth without evolving financial crime systems and controls."

Effectiveness is an architectural test about making controls work, not documenting them. A bolt on control regime can satisfy every technical requirement and still fail an effectiveness review, the more so as AI-driven onboarding fraud grows. Organisations treating compliance as policies find the gap only under supervision. Passing a security audit is not being secure; a reporting requirement met on paper is not surviving security testing, and a checklist is not a system built secure by design.

How Bolt-On Controls Break Under Scale

A bolt on financial-crime architecture produces four structural failures as a platform grows, each with a security rhyme, a security risk, and a real security cost. Evidence fragments across systems. Personal identity records sprawl across integrations. Re-verification cost compounds with each new platform. And the regime cannot prove a check ever ran. A secure by design architecture avoids all four, and a fast-scaling business and its security teams feel the security problems first.

Fragmented evidence

Bolt on controls scatter their output across ticketing systems and spreadsheets; when a regulator asks what was checked, the answer is assembled by hand through a manual process, at real security cost. The security rhyme is exact: security teams meet the same problem with security logs that were never built to be queryable. A documented process is not evidence; it is a record of intention — why process is not evidence is central to customer due diligence, and the onboarding process cannot bridge a record and the proof it worked.

PII sprawl across every integration

The bolt on model copies raw identity documents into every platform its users touch, so organisations must secure and re-audit each copy — a rising security burden, every duplicate another security liability that grows the security risks. This inverts GDPR Article 5, paragraph 1(c), which requires personal data be "adequate, relevant and limited to what is necessary" — the data minimisation principle. A secure by design system proves a status without moving the underlying records, so the security attack surface shrinks.

No verifiable proof of compliance

The regime can assert that a check happened but asks the counterparty to trust it, not verify it — there is no verifiable artefact to validate, only a claim backed by trust. That gap is what a secure by design approach closes, and what the W3C's verifiable-credential work makes routine. Confidence then rests on proof, not reputation or blind trust — the security response a bolt on regime cannot produce.

What Compliance by Design Looks Like for AML and KYC

Compliance by design means the control produces, at verification time, a portable, machine-checkable record of what was verified — the security property built into the attestation, not rebuilt later as a security afterthought to meet a regulatory requirement. That is the same secure by design principle, embedded in identity technology rather than added to it. The W3C Verifiable Credentials Data Model v2.0 (15 May 2025) expresses credentials that are "cryptographically secure, privacy respecting, and machine-verifiable." These verifiable credentials are the standards-level building block for any product that must prove compliance without seeing raw documents. Verifiability is a design process, not a report generated afterwards.

eIDAS 2 (Regulation (EU) 2024/1183, adopted 11 April 2024) establishes the European Digital Identity Wallet, letting users prove verified attributes without transferring the underlying documents — secure by design at the identity layer. It embodies data-protection-by-design: the proof travels, the raw file stays put. When privacy and security are properties of the architecture rather than policies stapled on, many organisations find data minimisation becomes the default, and the security posture holds without a requirement added late.

Compliance by design also means keeping the risk and security picture current. The EU's AMLR frames ongoing customer due diligence and ongoing review as obligations for obliged entities and their customers, and transaction-monitoring tools — Chainalysis, Elliptic, ComplyAdvantage — own the transaction-surveillance layer. That is the regulatory landscape, not one vendor's remit.

Verifier-Private Compliance Evidence: How We Approach It

This is the approach we take at Verifyo. A single Zero-Knowledge KYC attestation proves a user's compliance status — identity verified, age attested, and the AML screening set resolved at verification time: sanctions, PEP, criminal, barred, military and adverse-media checks — without transferring raw PII to the receiving platform. The platform receives a status check, not a copy of the product's documents, which means that the same privacy property holds across the network, so the security surface never grows. That design answers two failures: PII sprawl disappears because that identity file is never copied, and the no-proof gap closes because the attestation is itself the verifiable artefact. The distance between Traditional KYC vs Zero-Knowledge KYC is architectural, not cosmetic.

The attestation is reusable. One verification produces proof that integrating platforms accept through the public attestation, so the re-verification cost falls away and customers are not re-onboarded at each platform. A complete compliance stack means more than a verification-time check. Ongoing monitoring, business verification, and Travel Rule message exchange are obligations that live elsewhere, handled by transaction-monitoring platforms — the wider regulatory landscape, not one product's remit. Verifyo's live scope is verification-time Zero-Knowledge KYC and the AML screening attestation at Level 1. It does not run ongoing or transaction monitoring, does not verify businesses, and does not exchange Travel Rule data; those obligations sit with other layers of the stack or on the roadmap.

You cannot buy compliance as headcount and stacked tooling any more than you can buy security by bolting a scanner onto a shipped product. The organisations that survive scale and supervisory pressure built verifiable, privacy-preserving evidence into the architecture from the start. Compliance by design is not a slogan borrowed from cybersecurity; it is the same secure by design discipline that makes controls work and security hold. Regulators moving to effectiveness-based supervision have already chosen, and meeting that requirement means building for it — the platforms that build security into the design, not the ones bolting controls on, keep defences built to stand when the supervisor arrives.

Sources

1. CISA. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. October 2023. https://www.cisa.gov/resources-tools/resources/secure-by-design
2. NIST. Secure Software Development Framework (SSDF) Version 1.1, Special Publication 800-218. February 2022. https://csrc.nist.gov/pubs/sp/800/218/final
3. European Union. Regulation (EU) 2016/679 (GDPR), Article 25 — Data protection by design and by default. Adopted 27 April 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
4. European Data Protection Board. Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, Version 2.0. Adopted 20 October 2020. https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf
5. U.S. Department of Justice. Binance and CEO Plead Guilty to Federal Charges in $4B Resolution. 21 November 2023. https://www.justice.gov/archives/opa/pr/binance-and-ceo-plead-guilty-federal-charges-4b-resolution
6. FinCEN. FinCEN Announces Largest Settlement in U.S. Treasury Department History with Virtual Asset Exchange Binance. 21 November 2023. https://www.fincen.gov/news/news-releases/fincen-announces-largest-settlement-us-treasury-department-history-virtual-asset
7. U.S. Department of Justice, SDNY. OKX Pleads Guilty To Violating U.S. Anti-Money Laundering Laws And Agrees To Pay Penalties Totaling More Than $500 Million. 24 February 2025. https://www.justice.gov/usao-sdny/pr/okx-pleads-guilty-violating-us-anti-money-laundering-laws-and-agrees-pay-penalties
8. FATF. Methodology for Assessing Technical Compliance with the FATF Recommendations and the Effectiveness of AML/CFT/CPF Systems (2022 update). 2022. https://www.fatf-gafi.org/en/publications/Mutualevaluations/Fatf-methodology.html
9. FinCEN. FinCEN Proposes Rule to Fundamentally Reform Financial Institution Programs Designed to Fight Illicit Finance. 7 April 2026 (Federal Register 10 April 2026). https://www.fincen.gov/news/news-releases/fincen-proposes-rule-fundamentally-reform-financial-institution-programs
10. Financial Conduct Authority. Dear CEO letter: Common control failings identified in anti-money laundering frameworks. March 2024. https://www.fca.org.uk/publication/correspondence/dear-ceo-letter-action-response-common-control-failings-anti-money-laundering-frameworks.pdf
11. European Union. Regulation (EU) 2016/679 (GDPR), Article 5(1)(c) — Data minimisation. Adopted 27 April 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
12. European Union. Regulation (EU) 2024/1183 (eIDAS 2) establishing the European Digital Identity Framework. Adopted 11 April 2024. https://eur-lex.europa.eu/eli/reg/2024/1183/oj
13. W3C. Verifiable Credentials Data Model v2.0, W3C Recommendation. 15 May 2025. https://www.w3.org/TR/vc-data-model-2.0/