Managing scheme change: rulebook updates and the change calendar

Payment schemes change every year, and the change is mandatory. The European Payments Council publishes a new SEPA rulebook every year, effective in November, and every adherent must comply by the effective date. SWIFT publishes a standards release every year, effective in November, and every member must implement it. The card schemes publish rule changes throughout the year, with effective dates that the acquirers and issuers must meet. A firm that misses a scheme change cannot process payments, because the messages it sends will be rejected. The change calendar is the tool that manages this. It lists every scheme change, its effective date, its impact, and its owner, for the next 12 months. The calendar is built from the scheme's publications, the SWIFT standards release notes, the EPC change requests, and the card scheme bulletins. The calendar must be reviewed monthly, and the review must ask whether any change has moved, whether any new change has been published, and whether any change has been missed. A change that is discovered a month before its effective date is a crisis, and a change that is discovered after its effective date is an outage. The impact assessment is the first step for each change. The analyst must read the change, identify which messages, fields, reason codes, timelines or limits it affects, and estimate the work. A change to a reason code may require a change to the screening rules, the exception handling, the customer communication, and the reporting. A change to a message version may require a change to the mapping, the validation, the test pack, and the certification. The impact assessment must be written, reviewed, and approved before the work starts. The implementation of a scheme change has a fixed sequence. First the requirements are written, then the code is changed, then the internal tests are run, then the scheme test pack is run, then the certification is obtained, then the change is deployed to production, and then the production is monitored. The sequence cannot be shortened, because the certification is the gate, and the gate cannot be passed without the tests. The project plan must therefore be built backwards from the effective date, with enough time for a failed certification attempt. The most dangerous scheme changes are the ones that look small. A change to the maximum length of a name field from 70 to 140 characters looks small, but it affects the validation, the screening, the display, and the downstream systems that store the name. A change to a reason code from AM04 to AC04 looks small, but it affects the exception handling, the customer communication, and the reporting. A change to a cut-off time looks small, but it affects the liquidity forecast, the customer promise, and the operations rota. The impact assessment must therefore be thorough, even for small changes. Communication of a scheme change has three audiences. Customers need to know if the change affects them, for example if a cut-off time moves or a fee changes. Correspondent banks need to know if the change affects the messages they receive. Internal teams need to know the new rules, the new test cases, and the new procedures. The communication must be sent before the effective date, and must be clear about what changes and what stays the same. A change that is implemented but not communicated will generate support calls from customers who were not told. For a business analyst, the scheme change is a recurring requirements package. Each change gets its own requirements, its own impact assessment, its own test pack, and its own sign-off. The acceptance criteria must include a test where the change is implemented, certified, deployed, and monitored, with no payment rejected for the old reason after the effective date. Last reviewed 7 November 2026. Further reading: the European Payments Council rulebook change management process; the SWIFT standards release notes; the Visa and Mastercard rule change bulletins; the Bank of England guidance on payment system change management.