/finance-expert

The regulatory perimeter

Verified against primary sources on 2026-09-10. Dates and thresholds move; confirm the current text of any rule you are about to build against.

Regulation is not a layer you add before launch. It is a set of constraints on the shape of the system — what data may exist, where it may live, who may touch it, how long it must survive, what it must be able to prove, and how fast it must come back after a failure. Discovered late, those constraints are a rewrite. Discovered in §2 of the framing, they are a schema decision.

This file tells you which regime bites, what it demands of the system, and where the engineering question stops and the legal or compliance question starts. It is not legal advice. Nothing here authorises a design; it tells you which conversation to have and what to bring to it. Dates and statuses move — several regimes below were mid-flight through 2025–2026 — so wherever this file says "as of 2026", treat it as a pointer to the current text, not as the current text. And the standing rule: the regulator does not accept "the code does this" as evidence; it accepts an artifact — a log, a report, an approval record, a signed attestation — produced by a control you can describe and demonstrate. Design for the artifact (M14).

1. Determining your perimeter

Start from activity, not from product name. "We're a marketplace" tells you nothing; "we hold seller funds for 14 days before payout" tells you almost everything. Work the table top to bottom and write the answers into the spec. Each row's decision question is the one that settles it; if the answer is "maybe", it is a legal question, not an architecture question.

Two traps. First, the bank-partner illusion: routing money through a sponsor bank or a licensed PSP does not automatically move the obligation off you — it moves some of it, by contract, and the contract is the thing to read (§5). Second, scope creep by feature: a "store card for next time" checkbox, a "hold the payout until delivery" rule, or a "send balance to a friend" button each cross a regime boundary. Every feature that changes who controls funds, for how long, re-opens this table.

1.1 Perimeter as a spec artifact

Record the outcome as a table in FINANCIAL-SYSTEM-SPEC.md, not as prose. The "basis" column is the one that matters; an unexplained "No" is a finding.

2. The engineer's translation rule

Every regime in this file, whatever its subject, reduces to some combination of six system properties. This is why a well-built regulated system absorbs a new regime in weeks and a badly built one takes a year: the second one has to invent the primitives.

Read the columns, not the rows. Six primitives serve every regime: a tokenisation/minimisation boundary, an authorisation model with separation of duties (M11), an append-only audit trail (M14), a retention engine that distinguishes minimum from maximum, a report generator that runs off the ledger (M19), and a resilience programme with tested recovery. Build those six well and each new regime is a mapping exercise; build them per-regime and you will have four audit trails that disagree — and a money type, amount representation and rounding policy that differ by report (M4, M5, money-arithmetic.md).

3. PCI DSS v4.x

PCI DSS is contractual, not statutory — enforced by your acquirer and the card brands, with fines, forensic investigation costs and card-brand liability behind it. PCI DSS v4.0.1 (published 11 June 2024) is the only active version: v4.0 (March 2022) retired on 31 December 2024, and no v4.1 or v5 has been announced as of September 2026. v4.0.1 added and removed no requirements — it was a clarification release. Check the SSC document library anyway, because the Council revises SAQs, FAQs and the ROC template far more often than the standard. Requirements marked "future-dated" in v4.0 became mandatory on 31 March 2025; treat all of them as live now. See payments.md for the integration mechanics behind §3.1.

3.1 SAQ by integration pattern

Two warnings. The SAQ A eligibility criteria moved, and the move is a trap. In the SAQ A revision published January 2025 and effective 31 March 2025, the Council removed requirements 6.4.3, 11.6.1 and 12.3.1 from the SAQ A question set — and replaced them with an eligibility criterion: the merchant must confirm its site "is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". Nothing was relieved. The work moved from a question you answer to a condition you must satisfy before you may use the form at all, and the underlying PCI DSS requirements remain in force for everyone else. Read the current SAQ A before assuming an iframe integration is trivially in scope for it. And your SAQ is a floor: your acquirer can require more, and above a transaction volume threshold the brands require a QSA-signed ROC rather than a self-assessment.

3.2 What actually puts you in scope

In scope: any system component that stores, processes or transmits cardholder data (CHD) or sensitive authentication data (SAD); anything connected to or that could affect the security of those systems; and anything that can affect the security of the payment page as rendered in the customer's browser — the clause that catches most modern architectures, making your tag manager, analytics vendor, chat widget and CDN payment-page-security relevant even if PAN never touches your servers.

3.3 Scope-reduction patterns, ranked (M15 is the invariant; PCI is what finds you if you break it)

The objective is blunt: make the answer to "where is PAN?" be "in the PSP's vault, and nowhere else, ever." Every other design decision follows from that answer.

3.4 The requirements engineers actually implement

3.5 6.4.3 and 11.6.1 in practice on a real checkout page

These two turn checkout from a page into a controlled surface. Build them whether or not your SAQ asks the questions — for SAQ A merchants they are the substance of the eligibility criterion (§3.1), and everyone else answers them directly. Minimum viable implementation:

1. Inventory. A build-generated, machine-readable manifest of every script the page loads, direct and transitive, each with an owner, justification and approval date. A script that appears at runtime and not in the manifest is an alert.
2. Integrity. SRI on every static third-party script; for scripts that legitimately change, a pinned, versioned, self-hosted copy under your own change control. "We trust the vendor's CDN" is not an integrity mechanism.
3. Restriction. A strict Content-Security-Policy with an explicit allowlist (no unsafe-inline, no wildcard hosts), with report-to feeding an alert, not a dashboard nobody reads.
4. Tamper detection. Monitor the delivered HTML and the security-relevant response headers (CSP, HSTS, frame-ancestors) from outside your network, at least as often as your documented risk analysis requires, and alert on diff.
5. Governance. Adding a script to checkout is a change with an approver, not a tag-manager self-service action. Ask your marketing team whether they can push a tag to checkout without engineering approval; if they can, you have a finding, and it is the one the assessor will test.

3.6 Test data, fixtures and logs

Non-negotiable, and cheap to enforce mechanically (M15). No live PAN in test, staging, QA, demo, screenshots, support tickets or fixtures — brand test numbers only. No PAN, CVV, track data, PIN or PSP secret key in application logs, exception traces, APM payload capture, analytics events, session-replay tools or crash dumps; session replay on a checkout page is a specific, recurring, catastrophic pattern, so mask by allowlist, never by denylist. Redact at the emitter, not at the sink: if it reaches the sink, it happened. scripts/money_lint.py catches the obvious cases; test the redaction itself (M18).

4. EU payments: PSD2 today, PSD3/PSR next

4.1 The current frame

PSD2 (Directive (EU) 2015/2366) plus the SCA/CSC RTS (Delegated Regulation (EU) 2018/389) is the operative law across the EEA as of September 2026, transposed nationally, with EBA Guidelines and Q&As doing much of the real interpretive work. The Commission's 2023 package splits it in two: PSD3 (a directive: licensing, authorisation, supervision) and the PSR (a regulation: conduct rules, SCA, fraud, data access — directly applicable, so no transposition divergence). Status as of September 2026: agreed but not yet law. Parliament and Council reached provisional political agreement on 27 November 2025; the ECON committee approved the agreed texts on 5 May 2026; formal plenary and Council adoption and publication in the Official Journal are still outstanding. On the agreed shape, the PSR applies roughly 18 months after entry into force and PSD3 must be transposed within about the same window, putting real application in 2028 — confirm the OJ publication date, because every downstream deadline counts from it. FiDA, the Financial Data Access Regulation that would extend data sharing from payment accounts to the rest of financial services, is a separate proposal and is less advanced: the Council agreed its general approach on 2 December 2024, trilogues have run through 2025–2026, and there is no adopted text and no application date. Treat FiDA as a design assumption, not a deadline. Direction of travel worth designing toward now, because none of it is speculative in engineering terms:

Engineering consequence today: build IBAN–name (VoP/Confirmation of Payee) checks as a first-class step in the payment flow with its own recorded outcome, not a UI nicety; keep SCA outcomes as auditable events; and make consent/permission state a queryable object with an expiry, because a user-facing permission dashboard is coming and it must render from data you already keep (payments.md for the 3DS and rail mechanics; banking-open-finance.md for consent and the dedicated interface).

Do not wait for the PSR for any of that, because the Instant Payments Regulation already made most of it binding. Regulation (EU) 2024/886 amends SEPA and is in force now, on a staged calendar by currency area and firm type. Its engineering demands are unconditional: reachability 24 hours a day on any calendar day; funds available on the payee's account within 10 seconds of the payer's PSP receiving the payment order (Art. 5a(4)(c)) — a hard latency budget, not an SLO; charges no higher than the equivalent non-instant transfer; a Verification of Payee check on every euro credit transfer, instant or not (Art. 5c), before the payer authorises, and an inversion of the sanctions control: Art. 5d requires screening of your own payment service users at least once every calendar day and immediately after any new designation enters into force, and prohibits transaction-level sanctions screening during execution of an instant credit transfer. If your architecture screens synchronously in the payment path, that is now the non-compliant design for euro instant payments.

VoP is a match/close-match/no-match/not-possible outcome that must be presented to the payer before authorisation, recorded against the payment, and — where the payer proceeds against a mismatch — retained as the evidence that shifts liability. Model it as a state in the payment machine with four terminal outcomes and a stored response, never as a synchronous UI call whose result is discarded (M14).

The UK went further, earlier, and it is another hard timer. Since 7 October 2024 the UK Payment Systems Regulator's mandatory APP-scam reimbursement requirement (not to be confused with the EU PSR above) has applied to Faster Payments and CHAPS payments sent and received by UK PSPs: the sending PSP must reimburse within five business days of a claim (the clock pausable for information requests, with a longstop at the 35th business day), up to £85,000 per claim, with an optional excess of at most £100 — and the receiving PSP owes the sending PSP 50% of what was paid out. Two of those are schema decisions rather than policy ones: the 50/50 split is an inter-PSP receivable that has to be posted and reconciled (M16, M9), and the vulnerable-customer carve-outs (no excess, no gross-negligence exception) mean vulnerability is an attribute your claims engine must read.

The message format underneath all of this has also finished moving. Swift's ISO 20022 CBPR+ coexistence period for cross-border payments ended on 22 November 2025. MT payment instructions sent on FINplus after that are subject to additional validation and automatic conversion, and conversion became chargeable from 1 January 2026; MT 199/MT 299 for gpi tracking remain, deprecated, with no announced end date. The consequence is not "support a new format" but a data one: pacs.008/pacs.009 carry structured parties, structured postal addresses, purpose codes, remittance information and an end-to-end identifier that MT truncated. If your payment records were shaped by MT field limits, you are now storing less than the rail carries — which degrades sanctions screening, reconciliation matching (M9) and travel-rule data (§11.2) at the same time. Model the ISO 20022 fields, not the MT ones.

4.2 SCA and the exemption set

SCA = two independent factors from knowledge / possession / inherence, plus dynamic linking for remote payments (the authentication code is bound to amount and payee; changing either invalidates it). Dynamic linking is the part engineers get wrong: a generic OTP that authenticates a session rather than a transaction is not SCA.

Two rules. Exemptions are requests, not decisions — the issuer decides, and your flow must handle a soft decline with a step-up (M8-style retry semantics apply: the retry must be idempotent, M7). Whoever claims TRA must be able to evidence the fraud rate with a reproducible calculation from the ledger and the dispute records (M19). If you cannot produce that number on demand, you are not entitled to the exemption you are claiming.

4.3 Licensing shapes and what each means for the build

Being a PSP versus using one is the single largest architectural fork in this file. Using one, your system records claims and reconciles to an external authority. Being one, your system is the authority, and the regulator's questions ("every client's balance at close of business on 12 March, and the corresponding safeguarded funds") land on your schema.

4.4 Safeguarding, operationally

Safeguarding (PSD2 Art. 10 and its UK equivalent) means relevant funds are either segregated into a designated safeguarding account or secure liquid assets, or covered by insurance or a comparable guarantee. The UK reform has landed: FCA policy statement PS25/12 (August 2025) introduced an interim "supplementary regime" that came into force on 7 May 2026 for authorised payment institutions, and authorised and small e-money institutions — requiring daily internal and external reconciliation (each business day), a resolution pack retrievable within 48 hours, a distinct treatment for unallocated and unidentified funds, a monthly safeguarding return and an annual independent safeguarding audit. A later "post-repeal" regime modelled on CASS follows the legislative changes; it is not in force. What it means to your ledger (ledger.md for the account structures, reconciliation-close.md for the daily control):

If your system cannot produce "the safeguarding reconciliation for last Tuesday, with the break list and who closed each break", it is not safeguarding-ready regardless of what the bank account is called.

5. US money movement

5.1 State money transmitter licensing

There is no federal money-transmitter licence. Money transmission is licensed state by state (roughly all states plus DC and territories; a small number of outliers have historically not licensed — check current status), through NMLS, with divergent definitions, net-worth requirements, surety bonds, permissible-investment rules and reporting. The CSBS Money Transmission Modernization Act model law is slowly harmonising definitions — by 2026 well over half the states had enacted some version of it, and most of the rest had introduced one — but enactments vary in which articles they adopt and how they amend them. It is a trend, not a uniform code: check the enacting state's own text, not the model.

FinCEN MSB registration is separate and federal: money transmitters, dealers in foreign exchange, prepaid access providers/sellers and (per FinCEN's long-standing guidance) many convertible-virtual- currency businesses must register with FinCEN. Registration (Form 107) is due within 180 days of the date the MSB is established, then renewed by 31 December of the second calendar year following registration and every 24 months thereafter. Registration is not a licence and confers no authorisation; it is an AML-programme trigger (§6).

Where responsibility actually sits in a bank-partner model: legally with the bank, operationally with you, contractually wherever the agreement puts it. The bank's audit and its regulator's expectations therefore become your requirements — a control matrix, evidence of BSA/AML controls, change-management records, access reviews and incident reports, on the bank's timetable. Build §15 for the bank first.

5.2 ACH and the NACHA Operating Rules

The NACHA Operating Rules are contractual (through your ODFI) and are enforced with fines and, at the extreme, loss of ACH access.

5.3 Reg E (12 CFR 1005) — the timelines are the requirement

Reg E governs electronic fund transfers for consumer accounts. Its error-resolution clock is the most common source of "our system cannot do that" in US fintech, because the deadlines are unconditional.

Engineering translation: disputes are a first-class state machine with hard timers, not a support inbox. Every transition is logged (M14), every credit and debit is a posting (M1), every timer breach is an alert with an owner. A queue that relies on a human noticing an ageing ticket fails an examination.

5.4 Reg Z, and CFPB 1033

Reg Z / TILA (12 CFR 1026) governs consumer credit: APR calculation and disclosure, disclosure timing, credit-card rules (CARD Act — rate-change limits, payment allocation to highest-APR balances first, ability-to-pay), and billing-error resolution on open-end credit (broadly: acknowledge within 30 days, resolve within two billing cycles / 90 days). The sharp edges for engineers: the APR is a legally specified computation, not a business formula — implement it from the regulation's method and test it against published examples (M18); payment allocation order is prescribed; and disclosure timing is evidenced by system records, so log what was shown, when, and in what version.

CFPB 1033 (personal financial data rights). The October 2024 final rule set staged compliance dates starting 1 April 2026 for the largest institutions out toward 2030. It is not in effect. Sequence, as it stands on 10 September 2026: the Bureau reversed position in 2025 and issued an advance notice of proposed rulemaking in August 2025 to reconsider the rule; on 29 October 2025 the Eastern District of Kentucky (Forcht Bank v. CFPB) granted a preliminary injunction barring enforcement, holding the fixed compliance deadlines likely arbitrary and capricious because they depend on consensus standards that do not yet exist; the 1 April 2026 date therefore passed with no enforceable obligation; and in August 2026 the Bureau sent a replacement NPRM to OIRA for review — not yet published in the Federal Register. The rule is enjoined, not vacated, and the replacement is expected to revisit the fee prohibition, qualified third parties and liability allocation. Do not commit a roadmap to a compliance date until the new proposal is published and finalised. Build the capability regardless, because the market converged on it independently: token-based access instead of credential sharing, per-scope consent with expiry and revocation, a developer API with published performance metrics, and an audit trail of every third-party data access (M14). Note also that several states began legislating their own data-access rules in 2026, so "there is no federal rule" is not the same as "there is no obligation". See banking-open-finance.md for the API shape and FAPI-grade security profile.

6. AML/CFT

6.1 The source and the three layers

FATF's 40 Recommendations are the global source; they bind states, not you. States implement them, and that implementation binds you. The layers that matter:

6.2 What the law demands of the system

Tipping-off deserves a specific architecture note. A generic "audit everything into one queryable store" design (M14) collides with a legal prohibition on disclosure. The resolution is a separate, access-controlled compliance data store with its own authorisation model and its own audit trail of who read what — not a flag on a shared record. Support tooling must not render a reason code that reveals a filing. Test this like a security control (M18).

6.3 Where engineering stops

Engineering builds the mechanism; the compliance officer (MLRO/BSA officer) owns the calibration. Engineering does not choose risk-rating weights, monitoring thresholds, acceptable alert volumes, what constitutes suspicion, whether to file, whether to exit a customer, or the screening match threshold. Propose defaults, make them configurable with versioning and an approval record, and make every threshold change an auditable event with an approver (M11): a threshold changed by a deploy with no compliance approval is a finding, and a serious one. Implementation detail — scoring, screening architecture, case management, model governance — lives in risk-fraud-aml.md.

7. Financial reporting standards for engineers

The standard does not tell your accountant what to think; it tells your system what it must be able to produce and evidence. Treat each standard as a query specification, and each figure it yields as one that must carry its period, currency, basis and source when it reaches a human (M20, corporate-finance.md).

The common thread: every reported figure must be reconstructible from postings, with the inputs and the policy version that produced it (M1, M19). A revenue number produced by a spreadsheet reading the orders table is a restatement waiting to happen; the same number produced by recognition postings against the contract object is defensible. Recognition mechanics, deferred-revenue roll-forwards, the close calendar and the GL export live in reconciliation-close.md. Two boundaries: the choice of policy (recognition timing, ECL model, capitalisation) belongs to the finance owner and the auditor, and a policy change that affects published figures is a restatement with its own process — never a refactor.

8. SOX, in engineering terms

If you are listed on a US exchange or heading there, SOX section 404 makes management assert — and, over a size threshold, the external auditor attest to — the effectiveness of internal control over financial reporting (ICFR). For engineers this materialises almost entirely as ITGCs over the systems that produce or affect financial data.

Why a shared production admin account is an immediate finding. It destroys attribution: no control that depends on "who did this" can operate, so change management, SoD, access review and log integrity all fail simultaneously from one root cause. It is also unfixable retroactively — you cannot reconstruct who used ops-admin last quarter. Named identities with assumed roles, MFA, session recording for privileged access, and time-bounded elevation are the fix — and they must be in place before the audit period you intend to rely on, because auditors test operating effectiveness over a period, not design at a point in time. Two corollaries: start early (a control that has operated for six weeks cannot support an annual assertion), and scope deliberately (a clear, defended scoping with data-flow diagrams is cheaper than defending every service you own).

9. Banking prudential, briefly

If you are a bank — or you supply a bank — Basel III and its "Basel III finalisation"/"Basel IV" package (output floor, revised credit-risk standardised approach, revised operational risk, FRTB market risk) reaches engineering almost entirely through reporting and data lineage, not through the capital maths itself. Implementation dates have diverged so far that there is no longer a meaningful global date — state the jurisdiction, and do not assume a common timetable. Where it stands on 10 September 2026:

What the package asks of the system is stable across all three, whatever their dates:

The design rule: a regulatory return is a report from the ledger and its source systems (M19), with lineage metadata attached to every figure. If a number in a return cannot be traced to postings and source records without a human explaining a spreadsheet, that is the finding.

10. Markets

Cross-ref markets-trading.md for order lifecycle, instrument identifiers and P&L; here, only the regulatory obligations that shape the system.

RTS 25 has a quiet architectural consequence: NTP over the public internet on a cloud VM is generally not sufficient evidence of traceability for the tighter tiers. Decide that before choosing a deployment topology, not after.

11. Crypto

11.1 MiCA (EU)

Regulation (EU) 2023/1114. The asset-referenced/e-money-token titles applied from 30 June 2024 and the remainder from 30 December 2024, with member-state transitional ("grandfathering") windows for existing providers. Those windows are closed. ESMA confirmed in 2026 that the transitional period expired uniformly across the EU on 1 July 2026, with no extensions and no member-state variation: an entity providing crypto-asset services to EU clients without a MiCA authorisation is in breach of EU law and must have executed a wind-down plan, and NCAs were directed to act against unauthorised provision. The live questions are now operational, not transitional — is your authorisation actually granted (not pending), does the service list on it cover what you ship, and is your passport notification in place for each member state you serve.

11.2 The travel rule

FATF Recommendation 16 extended to virtual assets: originator and beneficiary information must accompany qualifying transfers between VASPs. In the EU, Regulation (EU) 2023/1113 (the recast Transfer of Funds Regulation) has applied to crypto-asset transfers since 30 December 2024, with no de minimis threshold, alongside the EBA's Travel Rule Guidelines. The US BSA travel rule threshold remains $3,000: the 2020 joint FinCEN/Federal Reserve proposal to cut it to $250 for cross-border transfers and to name convertible virtual currency explicitly was never finalised, so it is a proposal, not a rule. Engineering consequences: a counterparty-VASP directory and its trust model; a protocol implementation (IVMS 101 over one of the messaging networks); handling of transfers to self-hosted wallets, which carry their own verification expectations; and a blocking decision point — the transfer does not leave until the data obligation is satisfied or an exception is recorded. Build it as a step in the payment state machine with its own posting-relevant outcome, never as an async afterthought.

11.3 US status, stated carefully

As of 10 September 2026 the US framework is partially built and moving. Stablecoins: the GENIUS Act was enacted on 18 July 2025, creating a federal framework for payment stablecoin issuers — permitted issuers only; reserves backing outstanding stablecoins on an at least one-to-one basis in a closed list of eligible assets (US currency and Federal Reserve balances, insured demand deposits, Treasuries with 93 days or less remaining maturity, overnight Treasury-backed repo, and money market funds holding only those); monthly public reports of outstanding supply and reserve composition, examined by a registered public accounting firm and certified by the CEO and CFO under criminal penalty; redemption on a published policy; BSA/AML and sanctions programme obligations; and a prohibition on paying interest or yield to a holder solely for holding the stablecoin. It takes effect on the earlier of 18 months after enactment (18 January 2027) or 120 days after the primary federal regulators issue final implementing regulations. Rulemaking is under way but unfinished: the OCC proposed rules in March 2026 and Treasury's NPRM on issuance, offer and sale was published 18 August 2026 with comments due 19 October 2026. No final rules yet, so the effective date is currently tracking the January 2027 backstop. Market structure: the CLARITY Act (H.R. 3633) passed the House in July 2025 and remains before the Senate, where procedural votes opened in August 2026 and a floor vote slipped into September 2026. It is not law. Do not build to a claimed SEC/CFTC boundary that Congress has not drawn. Everything else remains in force meanwhile: FinCEN MSB registration and the BSA for exchangers and administrators; OFAC sanctions including sanctioned addresses (screening on-chain counterparties is an operational requirement, not an option); state regimes including NYDFS and state MTLs; SEC and CFTC enforcement under existing law; and IRS digital-asset broker reporting on its own phased dates. Custody accounting moved too: SAB 121 was rescinded in early 2025 (SAB 122), changing balance-sheet treatment for entities safeguarding crypto for others (§7). The engineering-safe position: build for segregation, per-client entitlement accounting, on-chain reconciliation, sanctions screening and travel-rule data regardless of which US regime lands — every plausible outcome requires all five.

12. DORA

Regulation (EU) 2022/2554, applicable since 17 January 2025, covering essentially all EU financial entities (banks, PIs, EMIs, investment firms, insurers, CASPs, trading venues and more) plus, indirectly, their ICT providers. DORA is the regime that turns "resilience engineering" into a legal obligation with deadlines.

Worth acting on even outside the EU: a dependency inventory generated from infrastructure-as-code and service manifests rather than by hand; incident classification implemented as a decision function with logged inputs; and DR objectives tested and evidenced rather than asserted — for a ledger the only acceptable RPO for committed postings is zero, and you must prove it (architecture-ops.md).

13. Privacy versus financial record-keeping

13.1 The collision

GDPR requires erasure on request (Art. 17) and storage limitation (Art. 5(1)(e)); the ledger requires immutability (M3) and the regimes above require multi-year retention. Reconcilable, but only by design, and only if you separated the data in the first place (ledger.md).

13.2 Accepted resolutions

What is not an acceptable resolution: deleting or editing postings (M3), overwriting a name in place in an append-only store (the prior version is still in the log), or refusing the request outright without a documented legal basis for the refusal.

13.3 DSARs in a ledger system

A subject access request in a financial system is an engineering feature, not a manual export. Build it: a documented inventory of every store holding personal data (the Record of Processing Activities made executable); a query per store keyed on the subject identifier; assembly into a portable format; redaction of third-party personal data and of anything covered by the tipping-off prohibition or otherwise exempt (§6.2 — SAR/STR content must never appear in a DSAR response); a legal review gate before release; and a log of the request, the reviewer and the release (M14). The clock is one month, extendable by two for complexity. A system that cannot enumerate its own PII stores cannot answer a DSAR correctly, and that is the common failure.

13.4 Residency and transfers

Residency arises from three sources engineers routinely conflate — privacy law (transfer mechanisms), sector regulation (local processing or local records for supervised entities), and contract (a bank partner or enterprise customer imposing it). Resolve each separately.

Decide the residency model before the ledger's partitioning model. Retrofitting regional isolation onto a global ledger is one of the most expensive migrations in this domain.

13.5 Retention schedule as a table

Retention has a minimum (regulatory) and a maximum (privacy). The system must enforce both, and the gap between them is a policy decision with a named owner.

Encode this table as configuration that a retention job reads, not as tribal knowledge. Every deletion run writes an audit record of what class it removed and how many records (M14) — because "we deleted it on schedule" is itself something you will be asked to prove.

14. Tax obligations that reach engineering

The standing advice: integrate a tax engine; do not hand-roll rates. Rates, boundaries, product taxability, thresholds and nexus rules change constantly and per jurisdiction; a hard-coded rate table is a liability with a compounding interest rate. What you own regardless of the engine: the determination inputs (location evidence, product tax codes, entity and registration data), the posting of tax as a separate liability (M16) and the rounding policy applied to it (M5, money-arithmetic.md), the immutability of a cleared e-invoice (M3 — in a clearance country the invoice number sequence and its cleared state are regulated artifacts), and reconciliation between the engine, the ledger and the filed return (M9, M19).

15. Building for audit

Audit readiness is a system property. Firms that treat it as a quarterly scramble pay twice: once in engineering time reconstructing evidence, once in findings caused by evidence that does not exist.

15.1 The control matrix as an artifact

Maintain one document — versioned, in the repo, reviewed like code — mapping each obligation to a control, an owner, an implementation and its evidence:

Coverage is bidirectional: every obligation maps to at least one control, and every control maps to at least one obligation (a control with no obligation is either undocumented risk management or waste).

15.2 Evidence generation as a feature

Treat evidence like an API: a stable interface, a versioned query, reproducible output. Practically — each control's evidence is produced by a scheduled job that writes a timestamped, immutable artifact to audit storage with the parameters used; sampling is by a deterministic, documented method (auditors will re-run it); and evidence about a period is generated during that period, not reconstructed after it.

15.3 Log integrity

An audit trail that can be edited is not evidence. Minimum bar (M14): append-only storage with object-lock / WORM retention; write permissions separated from delete, with delete held by no standing human role; hash-chaining or periodic signed digests, stored under different control than the logs, so tampering is detectable; synchronised traceable time (M10, and §10 if markets rules apply); retention aligned to §13.5. Then falsify it — have someone with production access attempt an alteration and confirm they are both prevented and detected (M18).

15.4 Access review automation

Manual quarterly recertification consumes weeks and produces rubber-stamps. Automate: extract entitlements from every in-scope system on a schedule; join against the HR roster to flag leavers, transfers and dormant accounts; route each owner only their own delta; record decisions with timestamp and identity; auto-revoke on non-response; and emit the auditor's evidence pack as an output of the process. Non-human identities go through the same review — service accounts with standing production credentials and no owner are a recurring finding.

15.5 Regulatory change process

Regimes move; this file's own hedging is the proof. Keep a watchlist of the regimes in your §1.1 table with named owners; review on a schedule (quarterly, plus an event-driven path for consultations and final rules); make each change produce an assessment (does it apply, what changes, by when), a dated backlog item, and a control-matrix update; and re-run the §1 perimeter table annually, because your product changed even if the law did not.

15.6 Artifacts every regulated-adjacent system should be able to produce on request

If any of these takes days, that is the finding — before the auditor arrives.

Where to check the current text

This file was verified on 2026-09-10 and will decay. These are the sources to re-check against, not secondary summaries — the §15.5 watchlist should point here.

Review questions

1. For each activity in §1, has someone named recorded whether the regime applies and the basis for that answer — and would a new feature that changes who controls funds re-open the table automatically, or only if someone remembers?
2. Where is PAN, exactly, in every environment including test, logs, backups and analytics — and can you prove the answer mechanically rather than by assertion (M15)?
3. Who can add a script to the checkout page, and does that path include an approval and an integrity mechanism, or does a tag manager bypass both (PCI 6.4.3/11.6.1)?
4. If you claim an SCA exemption, can you reproduce the fraud rate that entitles you to it, from the ledger and the dispute records, for the relevant window (M19)?
5. If you hold client funds, can you produce every client's balance as at close of business on an arbitrary past date, reconciled to the safeguarding account, with the break list — and how long does it take (M1, M9, M10)?
6. Which of your regulatory clocks (Reg E error resolution, DORA 4/24/72 hours, DSAR one month, SAR deadlines) are enforced by timers and alerts in the system, and which depend on a human noticing a queue?
7. Can one identity write code, approve it, and deploy it to production — and is there any shared privileged account anywhere in the path to the ledger (M11, §8)?
8. When a customer demands erasure, what exactly happens to the postings, the PII, the KYC file and the backups — and is that answer written down with a legal basis, or improvised per request (M3, §13)?
9. Where does a number in your most regulator-facing report come from, step by step, and how many of those steps are a spreadsheet or a hand-run query (M19, §9)?
10. Which obligations in your control matrix have no evidence generated automatically — and what is the plan for the audit period that has already started?