Most engineers meet a regulation as a slide in a compliance deck or a Jira ticket that says "make this PSD2 compliant." By then the law has already been flattened into someone else's interpretation, and you inherit their guesses along with your own. The skill that pays off across every other module in this course is reading the source text yourself and decomposing it into the concrete things you have to build: a timer, a stored record, a screen the user cannot skip, a branch in your code.
A statute does not describe a feature. It describes an obligation. Your job is to translate that obligation into mechanisms that a system can execute the same way every time, and that an auditor can later inspect. This module is about that translation. The rest of the course applies it to specific regimes.
A rule is not one thing. It decomposes into four.
When you read a payments rule closely, almost every obligation it imposes lands in one of four buckets. Naming the buckets up front keeps you from collapsing the whole thing into a vague "we need to handle X."
Timing
A regulation rarely just says "do the thing." It says do it within a window, or no later than some count of days, or before some other event. These become timers, queues, and deadlines in your system, and they are usually the part teams under-build.
State and records
The rule assumes some fact is captured and retained: a consent was given, a decision was made, a notice was sent. If you cannot produce the record on demand, you did not comply, regardless of what your code did at runtime. This is the log layer.
Decision logic
The rule branches. It applies to this transaction type but not that one, to this customer but not that one, above a threshold but not below it. These become conditionals, and the cost of getting the boundary wrong is that you either block legitimate activity or wave through the thing the rule existed to catch.
User-facing interaction
Some obligations only exist as something the user sees or does: an authentication challenge, a disclosure, a consent screen, an explicit choice. The control lives in the interface, and a screen the user can dismiss without acting is often the same as no control at all.
A worked example: Regulation E error resolution
Take a US obligation that sounds like pure legal prose and watch it become a system. Under Regulation E (12 CFR 1005.11), when a consumer reports an error on an electronic fund transfer, a financial institution must investigate and resolve it on a defined clock.
The text gives you the raw material directly. A consumer's notice is only timely if the institution receives it no later than 60 days after it sent the periodic statement on which the error first appeared. The institution must investigate and determine whether an error occurred within 10 business days of receiving the notice. If it cannot finish in 10 business days, it may take up to 45 calendar days, but only if it provisionally credits the disputed amount to the account within those 10 business days and gives the consumer use of the funds. It must report the result to the consumer within three business days of completing the investigation, and correct a confirmed error within one business day of finding it.
Now decompose it against the four buckets.
Timing. You have at least four clocks: the 60-day inbound eligibility window, the 10-business-day investigation target, the 45-calendar-day extended ceiling, and the three-business-day result-notification window. Business days and calendar days are different counters, which means your date math needs a holiday calendar, not a simple +10. A naive day-count is one of the most common ways teams quietly fall out of compliance.
State and records. You need a durable case record per dispute: when the notice arrived, what the consumer alleged, the amount, every status transition, when provisional credit posted, when the result was sent. The case file is the thing an examiner reads. If your system resolved the dispute correctly but cannot show when each step happened, you have a finding waiting to happen.
Decision logic. The path forks on whether the institution can close within 10 business days. If yes, no provisional credit is required. If no, provisional credit becomes mandatory before the 10-day mark, and the clock extends to 45 days. There is also a separate branch for new accounts, where some windows widen. Each fork is a conditional you have to encode and test, including the boundary cases at exactly 10 days.
User-facing interaction. The consumer has to be told about the provisional credit, and about the final result. Those notifications are interface obligations with their own timing attached, and they need to be generated and logged, not left to a manual email someone may forget to send.
One paragraph of regulation became a state machine, a set of timers backed by a business-day calendar, a persisted case record, several branches, and two consumer notifications. That is the translation in miniature.
The same method, a different regime
The approach is regime-agnostic, which is why it carries into the EU and open-banking modules later. Read PSD2's strong customer authentication requirement the same way and the buckets fill differently. Decision logic decides when SCA is required versus exempt. User-facing interaction is the challenge itself, built from two of three independent elements: knowledge, possession, and inherence. State and records hold the authentication result and the dynamic linking of that approval to a specific amount and payee. The buckets are constant. What changes is which mechanism each obligation lands in.
How to do this in practice
Work from the primary text, not a summary. Regulations are written in numbered, hierarchical clauses precisely so that each obligation can be cited and isolated, and the official text and supervisory commentary will resolve ambiguities that a vendor blog will not.
For each clause, ask the four questions in order. Does it impose a deadline? Does it require a record I must be able to produce? Does it branch? Does it require something the user sees or does? Write the answer next to the clause. The gaps you find, the obligations with no mechanism behind them yet, are your actual backlog.
Then build the record layer as if an examiner will read it, because one might. The controls a system executes silently are worth nothing if you cannot later show that they ran, when, and on what input. Most regulatory findings are not "your logic was wrong." They are "you cannot prove your logic ran."
Takeaway
A regulation is a specification you have to compile. Decompose every obligation into timing, state and records, decision logic, and user-facing interaction, build each as a real mechanism rather than a policy document, and make the record layer first-class. Do that here and the remaining modules become applications of one method rather than eight separate puzzles.