The individual controls — KYC, AML, screening, audit, privacy, reporting — aren't separate products; they're facets of one system that shares data, decisions, and evidence. Building a compliance platform means engineering them as a coherent whole, with the auditability, explainability, and testability that turn a pile of checks into a defensible program. This is where the series comes together.
The individual controls — KYC, AML, screening, audit, privacy, reporting — aren't separate products; they're facets of one system sharing data, decisions, and evidence. Building a compliance platform means engineering them as a coherent, auditable, testable whole.
Every compliance control eventually produces something you must tell a regulator: a suspicious activity report, a transaction report, a periodic filing. Regulatory reporting is where your internal compliance data becomes an external, deadline-bound, precisely-formatted obligation — and it's an unglamorous data-engineering problem where accuracy and timeliness are legal requirements, not quality goals.
Every compliance control eventually produces something you must tell a regulator: a suspicious activity report, a transaction report, a periodic filing. Reporting is where internal compliance data becomes an external, deadline-bound obligation where accuracy and timeliness are legal requirements.
Compliance requires you to collect and keep a great deal of personal data; privacy law requires you to protect it, limit it, and sometimes delete it. Data privacy is the compliance domain that governs the data all the other controls depend on — and it turns "how you handle personal information" from a courtesy into a set of enforceable engineering obligations.
Compliance requires you to collect and keep a great deal of personal data; privacy law requires you to protect it, limit it, and sometimes delete it. Data privacy governs the data all the other controls depend on — turning data handling into enforceable engineering obligations.
Compliance ultimately comes down to one demand: prove it. Prove you verified the customer, prove you screened the transaction, prove you investigated the alert. The audit trail is how you prove it — an immutable, complete record of what happened and why — and it's the quiet backbone that makes every other compliance control defensible.
Compliance ultimately comes down to one demand: prove it. Prove you verified the customer, screened the transaction, investigated the alert. The audit trail is how you prove it — an immutable, complete record — the backbone that makes every other control defensible.
Sanctions screening looks simple — check if a name is on a list — and is genuinely hard, because names are messy, lists are fuzzy, and the penalty for a miss is among the most severe in all of compliance. It's a string-matching problem with strict-liability stakes, which is exactly what makes the false-positive-versus-false-negative balance so unforgiving.
Sanctions screening looks simple — check if a name is on a list — and is genuinely hard, because names are messy, matching is fuzzy, and the penalty for a miss is among the most severe in compliance: a string-matching problem with strict-liability stakes.
Knowing your customer is the front door; watching what they do is the rest of the house. AML transaction monitoring is the always-on system that scans activity for signs of money laundering — and it's a fascinating engineering problem precisely because the signal is rare, the cost of missing it is severe, and the cost of over-flagging drowns your investigators.
Knowing your customer is the front door; watching what they do is the rest of the house. AML transaction monitoring scans activity for signs of money laundering — a fascinating problem because the signal is rare, misses are severe, and over-flagging drowns investigators.
Before you can serve a customer in a regulated business, you have to answer a deceptively hard question: are they really who they claim to be? KYC turns that question into an engineering pipeline — collect, verify, screen, risk-assess — and getting it right means balancing legal rigor against an onboarding experience that doesn't drive legitimate customers away.
Before you can serve a customer in a regulated business, you have to answer a deceptively hard question: are they really who they claim to be? KYC turns that into a pipeline — collect, verify, screen, risk-assess — balancing legal rigor against onboarding friction.
In a regulated business, compliance is not paperwork bolted onto the product — it's a set of hard requirements woven through the code, and treating it as an engineering discipline rather than a legal afterthought is what separates companies that scale safely from ones that get shut down. RegTech is the practice of building compliance in, as software.
In a regulated business, compliance is not paperwork bolted onto the product — it's hard requirements woven through the code, and treating it as an engineering discipline rather than a legal afterthought separates companies that scale safely from ones that get shut down.
The DevSecOps series finale — shifting right to runtime, turning compliance into code, closing the incident feedback loop, measuring what matters, and the culture that makes secure the default path.
The capstone: shifting right to continuous security — runtime detection and vulnerability management as a loop, security observability and tamper-evident audit, compliance-as-code with evidence from the pipeline, metrics that matter, and the culture (paved roads, champions).
The capstone of this series — assembling roles, a use-case inventory, lifecycle gates, and policy-as-code into a right-sized governance program that produces evidence instead of paperwork, without crushing the velocity of a two-person team or failing an enterprise audit.
The capstone: assemble a right-sized governance program — roles and accountability, a model/use-case inventory as the backbone, lifecycle gates, and policy-as-code that blocks deploy when an owner, risk tier, model card, eval pass, or monitor is missing.
How an engineer should read AI regulation without a law degree — what the EU AI Act, ISO/IEC 42001, the NIST AI RMF, and sector rules actually ask for, and how each obligation maps to a control or artifact your pipeline can already produce.
Orient in AI regulation and translate it into controls (not legal advice): the EU AI Act's risk tiers and obligations, ISO/IEC 42001 as a certifiable AI management system, NIST AI RMF, and a crosswalk mapping each obligation to the artifact that satisfies it.
Why enterprises pick watsonx for its governance story, what watsonx.governance actually gives a Python team, and how to wire monitoring, factsheets, and generative-quality metrics into an LLM feature — honestly, as the platform-heavy work it is.
Governance is why many enterprises pick watsonx: model inventory, automated factsheets, monitoring (quality, drift, bias, and generative metrics like faithfulness), explainability, and EU AI Act-aligned risk workflows — with the ibm-watsonx-gov evaluation SDK and what to log.
Governance is the one phase whose ordering is non-negotiable: every major framework treats it as a lifecycle function established up front, and retrofitting it after an incident is how you end up with unexplainable models and regulatory exposure.
Governance is the one phase whose ordering is non-negotiable — established before real users, not retrofitted after an incident. Phase 1: NIST AI RMF, EU AI Act risk tiers, ISO 42001, and the artifacts to produce now.
The evidence layer of AI governance — how model cards, datasheets, system cards, and automated FactSheets turn "trust us" into an auditable paper trail, and why the EU AI Act makes these artifacts the actual deliverable.
The transparency artifacts that make AI governable: model cards, datasheets, and system/use-case documentation — plus a Python snippet that auto-captures lineage (model version, prompt hash, dataset version, eval scores, git SHA) into a card at build time, so docs are generated not hand-maintained.
Turning the four functions of the NIST AI Risk Management Framework — GOVERN, MAP, MEASURE, MANAGE — into something an engineering team can actually run: a risk taxonomy for LLM apps, a versioned risk register in code, and the eval hooks that keep MEASURE honest.
Make the NIST AI Risk Management Framework actionable: the Govern/Map/Measure/Manage functions in your own words, a risk taxonomy for LLM apps, and a versioned risk register (YAML/Python) capturing per-use-case risks, likelihood/impact, mitigations, and owners.
A working definition of AI governance for engineers — what it means, how it differs from security and compliance, why you already own a slice of it, and the frameworks and lifecycle map that anchor the rest of this series.
The opener to a governance series for engineers: what AI governance is and how it differs from security and compliance, why engineers produce the evidence (docs, evals, monitors, audit trails), and the frameworks used throughout — NIST AI RMF, the EU AI Act, and ISO/IEC 42001.
The last mile of a financial system isn't code — it's who can do what, who approves it, and how you prove the whole thing is correct.
The last mile isn't code — it's who can do what, who approves it, and how you prove it's correct. Segregation of duties, four-eyes, an auditable change trail, and property tests that assert ledger invariants over thousands of scenarios.
In finance you never update and never delete — you only append. Event sourcing gives you a perfect audit trail; the right to be forgotten is where it fights back.
In finance you append, never update or delete. Event sourcing gives a perfect audit trail; the right to be forgotten is where it fights back — and crypto-shredding is how you reconcile the two.
Large language models earn their place in regulated finance as fast, well-supervised assistants — not as autonomous agents with a hand on the money.
Where LLMs fit in regulated finance: document analysis/extraction, retrieval-grounded Q&A, and agentic decision support — plus the guardrails (grounding, human-in-the-loop, output validation, audit trails) that keep them…
Financial ML lives under regulators, adversaries, and money-denominated errors — so you design backward from a business metric, not forward from a model.
What sets financial ML apart from general ML: strict regulatory scrutiny and mandatory explainability, high-stakes and immediately quantifiable errors, messy multi-source data, non-stationarity, and adversarial actors.
How the two Basel liquidity ratios are computed from raw positions, and why the hard part is a data pipeline, not a formula.
How the Liquidity Coverage Ratio and Net Stable Funding Ratio are computed: HQLA classification, outflow factors, and the reporting pipeline.
How a trade turns into a regulator-ready report — eligibility, enrichment, validation, submission, and the break management loop that keeps you compliant.
The trade/transaction reporting pipeline: eligibility, enrichment (LEI/UPI/UTI), validation, submission to the ARM/TR, and break management.
Turning geography, product, channel, and behavior into a single defensible number — and a due-diligence tier a regulator can follow.
Building a customer risk-rating model: risk factors, weighting, thresholds to due-diligence tiers, and explainability for regulators.
Retiring the calendar-driven refresh and rebuilding customer due diligence as an event-driven state machine with regulator-grade audit evidence.
Moving from periodic review to event-driven pKYC: trigger events, risk re-scoring, refresh workflows, and audit evidence.
Treating fraud, credit, and risk models as governed assets with a lifecycle, an inventory, and an audit trail regulators can actually read.
Development, independent validation, approval, monitoring, and retirement of risk/fraud/credit models under SR 11-7-style governance.
Modeling borrower hardship as an explicit state machine, so relief, delinquency, and accounting never disagree.
Modeling hardship: payment holidays, term extensions, re-aging, and how restructuring interacts with delinquency and accounting.
Cluster and risk-score blockchain addresses for on-chain AML and sanctions exposure.
Cluster and risk-score blockchain addresses for on-chain AML and sanctions exposure.
Deciding low-value, TRA, and trusted-beneficiary exemptions so low-risk payments stay frictionless while genuine risk gets challenged via 3DS.
Decide PSD2 SCA exemptions (low-value, TRA, allowlist) to keep low-risk payments frictionless around 3DS.
Turn ICT asset and third-party risk, incident classification, and reporting into a system you can actually run — with a resilience-testing loop that keeps it honest.
Engineer DORA operational resilience: ICT asset/third-party risk, incident classification, reporting, and resilience testing.
Classify account tax residency and generate withholding and FATCA/CRS reporting files.
Classify account tax residency and generate withholding and FATCA/CRS reporting files.
A document and liveness pipeline that emits a graded pass, refer, or fail instead of a coin-flip yes/no.
Build a document + liveness/biometric identity-verification pipeline that returns a graded decision.
Turn AML alerts into investigated cases and filed SAR/STR reports, complementing rule-based monitoring.
Turn AML alerts into investigated cases and filed SAR/STR reports, complementing rule-based monitoring.
How to build PSD2-grade open-banking APIs — strong customer authentication and its exemptions, the consent grant and its revocation, and the hard boundary between account-information and payment-initiation scopes.
Teaches how to build open-banking APIs: strong customer authentication and exemptions, consent grant/lifecycle, account-information vs payment-initiation scopes, and TPP authorization with token/consent revocation.
How to turn a book of exposures into risk-weighted assets and a capital ratio with a deterministic, auditable pipeline
Teaches the engineering of a risk-weighted-asset calculator: exposure classification, risk-weight lookup (standardized approach), credit-conversion factors for off-balance items, and capital-ratio aggregation for regulatory reporting.
Typology rules, sliding-window aggregation, alert scoring, and case management that feeds STR/SAR filing — treated as a streaming systems problem, not a compliance checkbox.
Teaches how to build AML transaction monitoring: typology rules (structuring, rapid movement, layering), sliding-window aggregation, alert scoring and deduplication, and case management feeding STR/SAR filing.
How to exchange originator and beneficiary data between crypto services before a transfer settles: counterparty discovery, IVMS101 payloads, and pre-transfer verification that gates the on-chain send.
Teaches how to implement the FATF Travel Rule between VASPs: originator/beneficiary PII exchange protocols (IVMS101, TRP/OpenVASP), counterparty VASP discovery, and pre-transfer verification before on-chain send.
Model corporate ownership as a graph, propagate percentages through the chains, handle the cycles that break naive traversal, and surface every natural person who controls more than 25 percent — with the evidence path attached.
Teaches how to compute ultimate beneficial ownership: modeling ownership as a graph, percentage-through-chain calculation, control vs ownership thresholds, and cycle handling to surface >25% beneficial owners.
When software holds the card and clicks "buy," the old questions — was this the cardholder, did they mean to, who pays if not — all get harder to answer.
The new fraud surface: prompt injection turning a shopping agent into an attacker's buyer, hijacked delegated credentials (Visa saw ~450% more dark-web 'AI Agent' chatter in H1 2026), and disputes when an agent acted on…
How to ingest watchlists, match names across scripts and spellings, and turn a fuzzy score into an auditable clear, alert, or block.
Teaches how to build sanctions/watchlist screening: list ingestion (OFAC/UN/EU), transliteration and fuzzy name matching, scoring thresholds, whitelisting, and rescreening on list deltas to control false positives.
Studying for the IAPP AI Governance Professional credential? Here's an open-source Go codebase that demonstrates ~70% of the body of knowledge in working code.
Enough to reconstruct, never enough to leak. The audit event schema problem under §164.312(b), and how to solve it without conflating the audit sink with the PHI sink.
The 21st Century Cures Act §3060 CDS carve-out criterion 4 expressed as a code-level queue, lossless on reject, with audit-recorded reviewer rationale. Build it once, satisfy GDPR Article 22 for free.
What HIPAA looks like when you express it as Go interfaces — governance policies, append-only audit at DB GRANTs, PHI redaction at the logger seam, and HITL as the §3060 CDS carve-out criterion 4.
If you encode each SOC 2 control as a Terraform module, the audit becomes a check against module usage rather than a per-resource review. Notes from Bloom and adjacent projects.
Borrower onboarding is the most fraud-prone moment in a P2P platform. The shape that worked: deterministic KYC, parallel bureau pulls with fallback, real-time fraud signals, and a maker-checker approval for every disbursement.
Handling user data used to be a technical matter; now it's a legal one, with real regulations, real penalties, and real obligations that engineers build software to satisfy. Privacy and compliance have become part of the job — and, along with the rest of this series' legal basics, they lead to the single most important lesson: legal literacy exists to tell you when you're out of your depth and need a real lawyer. This closing post covers privacy, compliance, and that essential meta-skill. (Educational, not legal advice.)
Handling user data used to be a technical matter; now it's a legal one, with real regulations, penalties, and obligations. Privacy and compliance are part of the job — and they lead to the most important lesson: legal literacy exists to tell you when you're out of your depth and need a real lawyer. (Educational, not legal advice.)
Board policy as a YAML file the risk team owns. Annexure VI as a database query. Every governance recommendation rendered as a file path in a Go repository.
The RBI FREE-AI incident reporting form, expressed as a Go struct and a Postgres table. Every entry is an auto-generated artefact from the runtime — not a form an operator fills in retrospectively.
Every one of the 26 RBI FREE-AI recommendations, mapped to a specific file in a working multi-agent platform. What's ✅ done, what's 🟡 partial, what's ⚪ honest gap.
PAN check-digit validation, Aadhaar offline KYC, DigiLocker, PEP/sanctions — all in Go code, not in a prompt. The LLM's job is to translate the verdict into something a human can read.
Two KYC pathways an Indian fintech has to support. The Master Direction (Video KYC, etc.) and Aadhaar Offline KYC. Different speeds, different evidence requirements, different audit shapes.
IAPP's AI Governance Professional certification covers a body of knowledge worth knowing whether you certify or not. The mapping from BOK to working Go code for the engineer who wants to understand AI governance practically.