Compliance as Software

Financial services, healthcare, and other regulated domains run on rules — who you can serve, what you must verify, what you must record and report — and increasingly those rules are enforced not by a compliance officer reviewing files but by systems. RegTech (regulatory technology) is the discipline of implementing compliance as software: KYC, AML, sanctions screening, audit trails, privacy, and reporting, built into the product. This series covers that engineering, and it starts with the mindset shift: compliance is a systems problem, and treating it as one is a competitive and survival advantage.

Compliance is an engineering requirement, not a nuisance

Engineers often experience compliance as friction — obstacles the legal team imposes that slow down shipping. That framing is a mistake, and an expensive one. In a regulated business, compliance requirements are functional requirements as real as “the payment must go through”: the business is legally not allowed to operate without meeting them, and failures carry consequences most product bugs don’t:

• Regulatory fines — significant financial penalties for compliance failures, sometimes severe enough to threaten the business.
• License loss — regulated businesses operate under licenses that can be revoked, ending the company.
• Criminal liability — in some cases individuals (executives, compliance officers) face personal liability.
• Reputational damage — being sanctioned or breached destroys the trust regulated businesses depend on.

Given those stakes, compliance isn’t a “nice to have” the product team tolerates — it’s a core requirement that must be engineered as carefully as any critical feature. The teams that internalize this build compliance in from the start; the ones that treat it as a bolt-on discover, painfully, that retrofitting compliance into a system not designed for it is enormously harder than building it in. Compliance is an architectural concern, not a final checklist.

Why compliance became software

Compliance was once manual — humans reviewing documents, checking names against lists, filing reports by hand. That model broke under modern scale and speed:

• Volume — a digital financial service onboards thousands of customers and processes millions of transactions; no human team can manually verify identities and monitor every transaction at that scale.
• Speed — customers expect instant onboarding and real-time transactions, incompatible with manual review that takes days.
• Consistency — humans apply rules inconsistently and make errors; regulators increasingly expect systematic, repeatable, auditable processes.
• Complexity — the rules themselves (across jurisdictions, product types, risk levels) are too intricate to apply reliably by hand.

So compliance became software: automated identity verification, real-time transaction monitoring, automated screening, immutable audit logging, and automated reporting. This is RegTech — using technology to meet regulatory obligations at the scale, speed, and consistency modern business demands. And it’s a two-sided coin: the same automation that lets a fintech onboard customers in minutes is also what lets it satisfy regulators that it’s screening and monitoring properly. RegTech isn’t overhead on the product; often it is the product’s ability to operate.

The core domains

This series maps the main areas where compliance becomes engineering, each a later post:

• KYC (Know Your Customer) — verifying who your customers are at onboarding: identity proofing, customer due diligence, risk assessment. You must know who you’re dealing with.
• AML (Anti-Money Laundering) — detecting and preventing the use of your system to launder money: transaction monitoring for suspicious activity. You must watch for misuse.
• Sanctions screening — ensuring you don’t do business with sanctioned individuals, entities, or countries: screening against watchlists. You must not serve prohibited parties.
• Audit trails — recording what happened, immutably, so you can prove compliance to regulators and investigate incidents. You must be able to show your work.
• Data privacy — handling personal data lawfully: consent, minimization, retention, erasure (GDPR and similar). You must protect the data you hold.
• Regulatory reporting — filing required reports to authorities accurately and on time. You must tell regulators what they require.

Together these are the machinery of operating legally in a regulated domain, and each is a genuine engineering problem — data pipelines, matching algorithms, immutable stores, workflows — not a legal formality. This series is the engineering of each.

The principles that run through all of it

Before the specifics, a few principles recur across every compliance domain and are worth holding as design values:

• Auditability is the meta-requirement. Above almost everything, you must be able to prove to a regulator that you did what was required — which means recording decisions, their inputs, and their reasoning, immutably. Nearly every compliance system is, at its core, a system for producing evidence. Design for “show your work” from the start (the audit-trails post).
• Build it in, don’t bolt it on. Compliance woven into the architecture (identity checks at onboarding, monitoring in the transaction path, audit logging everywhere) is robust; compliance retrofitted is fragile and incomplete. Treat it as a first-class concern in design.
• Risk-based, not one-size-fits-all. Regulation generally expects a risk-based approach — more scrutiny for higher-risk customers and transactions, less for low-risk — so compliance systems are graduated, not uniform. This recurs in KYC, AML, and beyond.
• Explainability matters. When a system makes a compliance decision (flag this transaction, reject this customer), you often must explain why — to auditors, regulators, or the affected person. This shapes how you build (favoring explainable logic and thorough logging), and it connects directly to the AI Governance concerns when ML enters the picture.
• Getting it wrong is costly both ways. Too lax and you enable crime and face penalties; too strict and you block legitimate customers and drown in false positives. Compliance engineering is constant tuning of that balance (vivid in the sanctions and AML posts).

These principles — auditability, build-in, risk-based, explainable, balanced — are the through-line of the series. With the mindset set, the next post starts at the beginning of the customer relationship: KYC and identity verification.

Key takeaways

• Compliance in a regulated business is a functional engineering requirement, not a legal afterthought: failures bring fines, license loss, criminal liability, and reputational ruin, so it must be engineered as carefully as any critical feature.
• Compliance became software (RegTech) because manual review can’t handle modern volume, speed, consistency, and complexity — automated verification, monitoring, screening, logging, and reporting are what let regulated businesses operate at all.
• The core domains are KYC (verify customers), AML (detect misuse), sanctions screening (don’t serve prohibited parties), audit trails (prove compliance), data privacy (protect data), and regulatory reporting (file required reports) — each a real engineering problem.
• Auditability is the meta-requirement: nearly every compliance system exists to produce immutable evidence that you did what was required, so design for “show your work” from the start.
• Recurring principles: build compliance into the architecture (don’t bolt it on), take a risk-based (graduated) approach, keep decisions explainable, and constantly balance too-lax (enables crime/penalties) against too-strict (blocks legitimate customers).

Further reading

• The Fintech Engineering Handbook series
• AI Governance for Engineers series
• Wikipedia — Financial Action Task Force