Every prior module taught you to read one layer of the stack. This one teaches you to read all of them at once, against a single feature you are about to ship. The skill that separates a compliant team from a lucky one is the ability to take a product spec and decompose it into the statutes, rules, and controls it quietly depends on, before legal finds them for you in production.
We will work one feature end to end: a "pay by bank" button at checkout for a US merchant, pulling funds from a customer's bank account over ACH. It looks like one button. It is a dozen rules wearing a trench coat.
The method: four passes over the same feature
Trace any feature through four passes. Each pass asks a narrower question, and each answer should land on a named owner and an artifact you can point to.
- Statute and rule. What law or scheme rule governs this money movement, and who enforces it?
- Obligation. What concrete duty does that rule create for us specifically?
- Control. What system, check, or process satisfies the duty?
- Evidence. What artifact proves the control ran, and where does an examiner find it?
The discipline is refusing to stop at pass one. "EFTA applies" is not a finding. "We send a Reg E error-resolution acknowledgment within the deadline, generated by service X, logged in table Y" is a finding.
Pass one and two: the rule and the duty
Our pay-by-bank button triggers a consumer-initiated debit over the ACH network. Two rule sources attach immediately, and they sit at different altitudes.
The federal layer: EFTA and Regulation E
Because the payer is a consumer and the rail is an electronic fund transfer, the Electronic Fund Transfer Act and its implementing Regulation E (12 CFR Part 1005) govern the relationship. This is the consumer-protection perimeter from Module 3, now made specific.
Reg E hands us duties we cannot design away. We owe initial disclosures before the first transfer. We owe an error-resolution process when a customer disputes a charge. And we inherit the unauthorized-transfer liability tiers: a consumer who reports a lost or stolen access device within two business days is capped at the lesser of $50 or the amount transferred, with the cap rising to $500 for later reports, and the consumer bears no liability for unauthorized transfers appearing on a statement if reported within 60 days of the statement being sent. Those numbers are not negotiable contract terms. They are the floor the law sets.
The scheme layer: Nacha Operating Rules
The ACH network is governed by the Nacha Operating Rules, a private rulebook enforced by contract down the chain from the originating bank. This is the licensing-and-scheme architecture from Modules 1 and 6: a private rule that binds us as tightly as a statute because our bank will offload any fine it eats.
A web-initiated consumer debit carries the WEB Standard Entry Class code, and WEB entries carry their own obligation. Since the rule supplementing fraud-detection standards took effect on March 19, 2021, an originator of WEB debits must use a commercially reasonable fraud-detection system that includes account validation before the first use of an account number and before any change to it. So the button cannot simply accept a routing and account number and fire a debit. Validating that the account exists and is open is a scheme requirement, not a nice-to-have.
Pass three and four: control and evidence
Now translate each duty into something that runs in our systems and leaves a trace.
Working example: the account-validation duty
Take the Nacha account-validation obligation and run the full trace.
- Rule: Nacha Operating Rules, WEB debit fraud-detection standard, effective March 19, 2021.
- Obligation: validate the account before first use or change.
- Control: at the point the customer links a bank account, we call an account-verification service (a microdeposit flow, a network database lookup, or an open-banking provider that returns account status) and block the debit if validation fails.
- Evidence: a row per linkage event recording the method used, the response, the timestamp, and the decision, retained on a schedule our bank's audit can reach.
That is one duty fully traced. Notice the control is a vendor choice with a cost and a latency, and the evidence is a schema decision. Both belong in the spec, not the post-incident review.
The Reg E error-resolution duty
Run the same trace on disputes.
- Rule: Regulation E, 12 CFR 1005.11.
- Obligation: investigate a customer's reported error and resolve it within the regulatory timeline, with provisional credit where required.
- Control: a dispute intake path (not a generic support ticket), a case workflow with the deadline clock built in, and a decision step that posts credit or a denial notice.
- Evidence: the case record with dated state transitions, the acknowledgment and resolution notices sent, and an aging report that proves nothing breached the clock.
The trap here is treating disputes as a CX problem. Reg E makes it a deadline-driven legal obligation with a paper trail, and the control has to encode the clock so a busy quarter cannot quietly blow it.
Where the duties stack
A single screen can carry obligations from multiple regimes at once. Our button also needs an authorization the customer can understand and that we can reproduce later, which is both a Reg E disclosure duty and a Nacha authorization-retention duty. One control, the stored and timestamped authorization record, satisfies both. Mapping that overlap is how you avoid building two systems for one requirement, or worse, building zero and assuming the other team owns it.
The artifact you produce
The output of this method is a feature-to-rule map: a table whose rows are obligations and whose columns are rule, owner, control, and evidence. It is the document you hand to an auditor, a partner bank's onboarding team, or a new engineer who asks why the linkage flow blocks on a vendor call.
For our one button, that table has rows for account validation, error resolution, unauthorized-transfer liability handling, authorization capture and retention, and consumer disclosures, before we even reach state money-transmission questions or the bank partner's own overlay rules. That is the honest surface area of "let users pay from their bank."
Takeaway
A feature is not done when it works. It is done when every rule it touches has a named owner, a running control, and an artifact that proves the control ran. Run the four passes, statute to control to evidence, on the next thing you ship, and you will find the obligations while they are still cheap to build for, instead of meeting them as findings.