The rulebooks that decide what your product is allowed to do, mapped to the systems that have to enforce them.
Nothing in the catalog explains how regulation becomes engineering. This course does: the path from statute (PSD3/PSR, 1033, Reg E, the GENIUS Act) down to a specific control, log, or consent screen in your product.
You will learn to read a regulation for the control it implies rather than the prose it contains, so you can scope the build before legal hands you a memo. Evergreen, because the method of reading regulation outlasts any single rule.
A method for turning legal text into the specific systems, logs, and screens it actually requires, so you build the right controls instead of guessing at intent.
How the EU is splitting its payments rulebook into a directive (PSD3) and a directly applicable regulation (PSR), and why that legal form changes how a firm reads, builds against, and complies with the rules.
Reg E (debit, EFT) and Reg Z (credit) draw the US consumer-protection line through dispute timers and liability shifts. This lesson maps the clocks and thresholds you have to build against.
A practitioner's comparison of the US Section 1033 data-rights rule and the EU's FIDA open-finance framework, and why the two regimes put the same right on opposite architectures.
The GENIUS Act and MiCA both convert dollar and euro stablecoins from crypto novelties into licensed payment instruments, and both do it by pulling issuers inside a bank-grade perimeter of reserves, redemption, and supervision.
A money-transmitter, EMI, or payment-institution licence is not a permission slip you file once. It is a standing set of build requirements that shapes your ledger, your treasury, your reconciliation jobs, and your org chart.
A single international payment can sit inside two or three legal regimes simultaneously. This lesson shows how to map those overlaps and build product so each rulebook is satisfied by data and routing decisions made before money moves.
Rules are visible in draft long before they bind. The teams that scope engineering off proposals, not final texts, ship on time and avoid the compliance scramble.
Take one payment feature, a "pay by bank" checkout button, and follow every rule it touches down to the code and runbook that implement it. This is the method you run on any new feature.