Most payments teams treat regulation as a deadline that arrives fully formed. A final rule lands, legal forwards a summary, and engineering gets handed a date that already feels late. That model fails because the expensive part of compliance is rarely the legal interpretation. It is the schema change, the new data field, the validation logic, the partner re-test. Those things take quarters, and the signal that they are coming is usually public months or years before the binding text exists.
The change-management muscle is the practice of reading rulemaking as it forms, mapping each proposal to the systems it would touch, and scoping engineering off drafts instead of final rules. Earlier modules covered specific regimes: the EU stack, the US consumer perimeter, open banking, stablecoins, licensing, cross-border. This module is about the operating discipline that keeps all of them from surprising you.
Rules are visible long before they bind
Regulators publish their thinking in stages, and each stage is a usable engineering signal if you know how to read it.
In the US, a typical sequence runs from an Advance Notice of Proposed Rulemaking (ANPRM), where the agency signals it is considering action and asks open questions, to a Notice of Proposed Rulemaking (NPRM) that contains actual draft regulatory text and a comment period of usually 60 days, to a final rule that responds to comments and sets compliance dates. By the NPRM stage you have draft text. That is enough to start scoping.
In the EU, the chain runs from Commission proposal through Parliament and Council to a published Regulation in the Official Journal, often followed by Regulatory Technical Standards from the EBA that fill in the operational detail. The high-level obligation and the technical "how" arrive at different times, which matters for sequencing your own work.
The point is that "the rule is not final yet" is not a reason to wait. A draft with concrete field-level requirements is a buildable spec, and waiting for the final text usually means starting the long-lead work too late.
Map proposals to systems, not to legal memos
A rulemaking tracker that only logs titles and dates is a calendar, not a muscle. The useful artifact maps each in-flight proposal to the specific systems, data, and partners it would touch, with an owner and a confidence level.
For each tracked item, capture a few things. What concrete obligation does the draft create, stated as a system requirement rather than a legal paraphrase. Which services own the affected data path. What the long-lead dependency is, meaning the thing that cannot be compressed near the deadline. And how stable the requirement is, since some details will shift between draft and final.
That last column is where judgment lives. You scope the stable parts early and hold the volatile parts. The skill is telling them apart.
A worked example: the SEPA structured-address deadline
Consider the move to ISO 20022 structured addresses in the euro area. From 15 November 2026, fully unstructured addresses are no longer permitted in SEPA payment messages, and address data must sit in dedicated structured fields such as Town Name and Country Code, with a hybrid format allowed as a stepping stone. The consequence of non-compliance is operational and immediate: rejected payments and broken straight-through processing.
The stable part of this requirement was knowable well in advance. Address data has to move from free-text blocks into tagged, machine-readable fields. That implies a data-model change, customer-data backfill, message-format updates, and re-testing with every counterparty bank. None of that is a same-quarter job, and none of it depended on the final wording being locked.
A team running the muscle would have opened a workstream the moment the requirement was concrete, scoped the data migration and message changes immediately, and treated the hybrid-format allowance as the volatile detail to confirm later. A team waiting for certainty would discover in 2026 that the long-lead item, cleaning and re-fielding years of customer address data, cannot be done in the time left.
Build the standing process, then accept that some rules reverse
A muscle is a routine, not a heroic sprint before each deadline. The minimum viable version has four moving parts.
A monitored source list, so the same regulators, registers, and standards bodies get checked on a fixed cadence rather than when someone remembers. A triage step, where new items are classified by whether they touch your systems at all, since most do not. A living tracker that ties live items to owners and long-lead dependencies. And a recurring forum where product, engineering, legal, and compliance review the tracker together, because the field-level reading only works when the people who build and the people who interpret are in the same room.
There is a hard case that the discipline has to absorb: rules that get delayed, enjoined, or reopened after you have started building. The US open banking rule under Section 1033 is the live example. The CFPB finalized it in October 2024 with a first compliance date of 1 April 2026 for the largest data providers, then reopened the rulemaking with an ANPRM in August 2025, and a federal court enjoined enforcement while the Bureau reconsiders.
This is exactly where a naive "build everything early" reading breaks. The answer is not to ignore early signals, and it is not to build the full spec on a draft that might move. It is to scope early, sequence by stability, and stage the volatile work so it can be paused or re-pointed cheaply. Standing up an authentication and data-access layer is durable infrastructure that holds value regardless of how 1033 resolves. Hard-coding one specific draft's field list and consent screens is the kind of bet that the reopening punishes. The tracker's confidence column is what tells you which is which.
The takeaway
Compliance dates are not the start of the work. They are the end of a clock that began when the proposal became public. The teams that ship on time read draft text as a spec, map each proposal to the systems and long-lead dependencies it touches, and separate the stable obligations they can build now from the volatile details they hold. Treat rulemaking as a continuously monitored input to your roadmap, not a periodic emergency, and the deadline stops being a surprise.