Chapter 40 — The Payments Change Log

It is a Tuesday morning. Your compliance officer forwards you a PCI Security Standards Council bulletin: 51 "future-dated" requirements just became mandatory. Your acquirer emails about Visa's latest rulebook edition — 40 pages of changes, effective immediately. Your engineering team asks whether the SWIFT CBPR+ cutover affects your settlement reconciliation. And someone in product wants to know if the EU's new instant payments mandate means you need to support SEPA Instant by next quarter.

You could spend the next two days reading primary sources. Or you could start here.

This chapter is a curated change log of the payments industry — a chronological record of the rule changes, rail upgrades, standards migrations, and regulatory shifts that materially affect how payments work. It is designed as a living reference: something you check quarterly, not something you read once and forget. The entries are drawn from primary sources (regulators, scheme operators, standards bodies), and each one tells you what changed, who changed it, and what it means for merchants and practitioners.

This log starts in mid-2023, because that is where operational relevance begins. For the long arc — from Sumerian grain loans to instant rails — the Timeline of Money, kept as a sub-page of this chapter, traces ten thousand years of the same patterns repeating.

How to Use This Log

This log works best in two passes.

First pass: scan the timeline in the Change Log section below for entries relevant to your geography, your payment methods, and your role. Each entry includes a merchant takeaway (operational impact on acceptance, fraud, reconciliation, or payouts) and a practitioner takeaway (system design, compliance, or integration impact). Read the ones that affect you.

Second pass: read the Patterns section to see the cross-cutting themes that connect individual changes into larger trends. These patterns tell you where the industry is heading, not just where it has been.

If you are new to payments, start with the significance framework in the next section — it explains why these particular changes made the cut. If you are a merchant, jump to the timeline and scan for entries tagged with your region. If you are a payments professional, read everything — every entry has a system design implication.

What Makes a Change "Significant"

Not every payments announcement belongs in this log. We apply five tests, and a change must pass at least two to be included.

Diagram 1: The significance decision tree. A change must pass at least two of these five tests to be included in the log.

Table 1: The five significance tests. Each entry in the timeline passed at least two of these tests. When you encounter a new payments announcement, running it through this framework helps you decide whether it requires immediate action or can wait for your next quarterly review.

The Change Log

What follows is a chronological record of the payments changes that matter most. Each entry identifies what changed, who changed it, and what it means — both for merchants running a business on top of the payments stack and for practitioners building and maintaining that stack. We start in mid-2023 and move forward chronologically through early 2026, covering 20 entries across regulation, standards, infrastructure, and competition policy.

August 2023 — Singapore Formalizes Stablecoin Regulatory Framework

Who: Monetary Authority of Singapore (MAS)

Singapore became one of the first major financial centers to publish a comprehensive regulatory framework for stablecoins. The framework applies to single-currency stablecoins (SCS) pegged to the Singapore dollar or any G10 currency, issued in Singapore. Issuers must maintain reserve assets in low-risk, highly liquid instruments and comply with capital, redemption, and disclosure requirements.

Merchant takeaway: If you accept stablecoin payments in Singapore or deal with Singapore-based stablecoin issuers, you now have a licensed counterparty — which means regulatory recourse if something goes wrong. For most merchants, this is not yet relevant to daily operations, but it signals that stablecoin acceptance will become a regulated option, not a gray-area experiment. (See Chapter 28 for how stablecoins fit into the broader payments landscape.)

Practitioner takeaway: System designers building stablecoin settlement or payout flows targeting Singapore must now handle issuer licensing status, reserve attestation data, and redemption SLAs as first-class integration requirements — not optional metadata. Treat the MAS framework as a template for what other jurisdictions will require.

March–April 2024 — EU Mandates Instant Euro Credit Transfers

Who: European Parliament and Council (Regulation 2024/886)

The EU's Instant Payments Regulation requires all payment service providers in the eurozone to offer instant euro credit transfers — with funds arriving in the recipient's account within 10 seconds, 24/7/365. The regulation phases in: receiving capability by January 2025, sending capability by October 2025. Pricing must not exceed the charge for standard (non-instant) credit transfers. The regulation also mandates Verification of Payee (VoP) — confirming that the recipient's name matches the account before the payment executes.

Merchant takeaway: If you sell in the EU, this directly affects your payout and refund options. Instant SEPA credit transfers become a baseline capability, not a premium add-on, and the pricing cap means your bank cannot charge you more for instant than for next-day. VoP adds a new pre-payment check that reduces misdirected payments — but also adds a step in the checkout or payout flow. (See Chapter 18 for how bank transfers and real-time payment rails work.)

Practitioner takeaway: Two system design implications. First, your payment processing must handle 24/7/365 inbound and outbound flows — weekend and holiday settlement is no longer optional. Second, VoP requires a pre-validation API call before payment execution, which means your payment orchestration layer needs a name-matching step that does not exist in most card flows. Design for the VoP call to be both fast (sub-second) and graceful when the match is partial or ambiguous.

April 2024 — CHIPS Migrates to ISO 20022

Who: The Clearing House (TCH)

The Clearing House Interbank Payments System (CHIPS) — which processes approximately $1.8 trillion in daily US dollar payments, by The Clearing House's own count, primarily cross-border and wholesale — completed its migration to ISO 20022 messaging. CHIPS now accepts and produces MX-format messages, aligning with the global migration that SWIFT and other major payment systems are pursuing.

Merchant takeaway: Most merchants do not interact with CHIPS directly — it is a wholesale and interbank system. But if you receive large-value cross-border payments (supplier settlements, treasury transfers, or high-value B2B invoices), the richer data in ISO 20022 messages may flow through to your reconciliation systems. Expect your bank to pass through more structured remittance data over time.

Practitioner takeaway: CHIPS joining the ISO 20022 ecosystem means US dollar wholesale payments now carry structured addresses, purpose codes, and richer remittance fields. If you build reconciliation or treasury systems that consume CHIPS-settled payments, update your parsers to handle MX message structures. The transition also validates that high-value, high-throughput systems can migrate without disruption — a reference point when planning your own migrations.

June 2024 — EU Launches Anti-Money Laundering Authority (AMLA)

Who: European Parliament and Council

The EU formally established the Anti-Money Laundering Authority (AMLA), a new supranational body headquartered in Frankfurt. AMLA will directly supervise the highest-risk financial entities across the EU and coordinate national supervisory authorities. It becomes operational in stages, with direct supervision beginning in 2028. AMLA complements the EU's broader AML package, which includes a new AML Regulation (AMLR) and a revised directive (AMLD6).

Merchant takeaway: If you are a payment facilitator, marketplace, or large merchant classified as an "obliged entity" under EU AML rules, you may eventually fall under AMLA's coordination scope — meaning your AML compliance will be judged against a single EU standard rather than varying national interpretations. For most merchants, the immediate impact is indirect: your payment service providers and banks will face more consistent supervisory expectations, which may tighten KYC and transaction monitoring requirements they pass on to you. (See Chapter 26 for how AML obligations affect payment operations.)

Practitioner takeaway: AMLA means AML rule interpretation converges across the EU. If your system handles onboarding, transaction monitoring, or suspicious activity reporting across multiple EU member states, start designing for a single rulebook rather than 27 national variations. The operational savings from convergence are real — but so is the compliance cost of meeting the most stringent interpretation as the baseline.

June–December 2024 — EU Markets in Crypto-Assets Regulation (MiCA) Becomes Operational

Who: European Parliament and Council

MiCA's implementation rolled out in two phases. Stablecoin provisions (Title III for asset-referenced tokens and Title IV for e-money tokens) applied from June 2024. Authorization requirements for crypto-asset service providers (CASPs) — covering exchanges, custody providers, and brokers — applied from December 2024. MiCA creates a single EU-wide licensing regime for crypto-assets, replacing the patchwork of national frameworks.

Merchant takeaway: If you accept cryptocurrency payments or use stablecoins for settlement in the EU, your service providers must now be MiCA-licensed. This is a good thing for merchants: licensed counterparties mean reserve requirements, redemption guarantees, and regulatory oversight that did not exist before. But it also means you need to verify that your crypto payment processor or stablecoin issuer actually holds a MiCA authorization. Unlicensed providers face enforcement. (See Chapter 28 for the practical mechanics of stablecoin and crypto payments.)

Practitioner takeaway: MiCA licensing means your integration with any EU crypto-asset service must validate the provider's authorization status — similar to how you would check a payment institution's license. Build provider-status checks into your onboarding and ongoing monitoring processes. Also note that MiCA's stablecoin reserve and redemption requirements create new data flows: reserve attestation, redemption processing SLAs, and whitepaper disclosures that your compliance systems may need to ingest.

July 2024 — Apple Opens NFC Access in the EEA

Who: Apple, following European Commission commitments

Apple committed to opening NFC chip access on iPhones to third-party payment and wallet developers in the European Economic Area (EEA). Previously, only Apple Pay could use the iPhone's NFC tap-to-pay functionality. The commitment, made to resolve an EU antitrust investigation, allows third-party apps to trigger contactless payments at the point of sale without routing through Apple Pay.

Merchant takeaway: This does not change your terminal hardware — NFC acceptance already works. What it changes is the competitive landscape for mobile wallets. Expect more wallet options to emerge for tap-to-pay in Europe, potentially with different fee structures, loyalty integrations, or checkout experiences. If you operate in the EEA, evaluate whether alternative NFC wallets offer better terms than Apple Pay's current arrangements. (See Chapter 22 for how wallets and proximity payments work.)

Practitioner takeaway: Third-party NFC access means your point-of-sale integration may need to handle wallet identification differently. When only Apple Pay could use iPhone NFC, the wallet was implicit. With multiple wallets triggering NFC, your terminal software may need to distinguish which wallet initiated the tap — affecting routing, tokenization handling, and receipt data. Watch for Apple's Host Card Emulation (HCE) API specifications and test early.

October 2024 — UK Mandatory APP Scam Reimbursement Goes Live

Who: Payment Systems Regulator (PSR)

The UK Payment Systems Regulator's mandatory reimbursement framework for Authorized Push Payment (APP) scams took effect on 7 October 2024. Under the rules, sending payment service providers must reimburse victims of APP fraud up to £85,000 within five business days, splitting the cost 50/50 with the receiving provider. Both sending and receiving firms now have financial liability for APP fraud — a fundamental shift from the previous voluntary code, which placed the burden primarily on the sending bank.

Merchant takeaway: If you receive payments via Faster Payments in the UK, you are now part of the fraud liability chain. Receiving-side firms face financial exposure for inbound payments linked to APP scams. This means your fraud monitoring on inbound payments matters, not just outbound — if scam-linked funds arrive in accounts you control, you share the reimbursement cost. Review your inbound payment screening and consider whether you need enhanced controls for high-risk payment patterns.

Practitioner takeaway: The 50/50 liability split between sending and receiving PSPs creates a new class of system requirement: receiving-side fraud scoring. Most fraud detection systems focus on outbound payments (is the payer legitimate?). Now you also need inbound risk assessment (is this incoming payment likely to be the proceeds of a scam?). Architect your fraud detection pipeline to score both directions. The five-business-day reimbursement clock also means your dispute resolution workflow needs SLA tracking that did not exist for push payments before.

October 2024 — US "Open Banking" Rule 1033 Finalized

Who: Consumer Financial Protection Bureau (CFPB)

The CFPB finalized its Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act. The rule requires banks, credit card issuers, and other financial data holders to make consumer financial data available to consumers and their authorized third parties through developer interfaces (APIs). Implementation is phased by institution size: the largest providers must comply by April 2026, with smaller institutions following in later waves through 2030.

Merchant takeaway: Rule 1033 is primarily about account data access, not payment initiation — but the downstream effects reach merchants. As consumers gain portable access to their transaction data, expect more comparison tools, account-switching services, and data-driven financial products that affect how consumers choose where to bank and how they pay. If you offer financing, loyalty programs, or subscription services, consumer data portability means your customers can more easily share (and move) their financial relationships.

Practitioner takeaway: If you build financial data aggregation, personal finance tools, or account-linking features, Rule 1033 replaces screen-scraping with structured API access — a fundamental architecture shift. Design for OAuth-based consent flows, standardized data schemas (likely aligned with FDX specifications), and consumer-revocable access tokens. The phased rollout means you need to support both legacy aggregation and new API-based access during the transition. One caveat: the rule's future is subject to ongoing legal and political developments — build flexibly.

January 2025 — DORA Applies Across the EU

Who: European Parliament and Council

The Digital Operational Resilience Act (DORA) became applicable on 17 January 2025, after a two-year implementation period. DORA requires all EU financial entities — including payment institutions, e-money institutions, and crypto-asset service providers — to implement comprehensive ICT risk management, incident reporting, digital operational resilience testing, and third-party risk management. Critically, DORA extends oversight to "critical ICT third-party providers," meaning the cloud platforms and software vendors that financial institutions depend on.

Merchant takeaway: If you hold a payment institution or e-money license in the EU, DORA applies directly to you. Even if you do not, your payment processors and banking partners are now required to demonstrate operational resilience — which means they may impose new requirements on you as part of their supply chain risk management. Expect updated service agreements with clearer SLA definitions, incident notification obligations, and possibly new contractual requirements for how you handle ICT risks in your own operations.

Practitioner takeaway: DORA's most significant architectural impact is the third-party risk management requirement. If your payments system depends on cloud infrastructure, SaaS platforms, or third-party APIs, you must now formally assess those dependencies' resilience — not just their uptime SLA, but their recovery capabilities, geographic redundancy, and incident response procedures. Build dependency maps, test failover scenarios, and document everything. The 2024 CHAPS outage — caused by a third-party supplier failure — is exactly the kind of event DORA is designed to prevent. (See Chapter 26 for how operational resilience fits into the broader risk and compliance picture.)

March 2025 — PCI DSS v4.x Future-Dated Requirements Become Mandatory

Who: PCI Security Standards Council

The 51 "future-dated" requirements in PCI DSS v4.0 and v4.0.1 became mandatory on 31 March 2025. These requirements had been optional ("best practice") since the standard's initial release, giving organizations time to prepare. Key mandatory requirements include: targeted risk analysis for controls with flexible frequency, automated log review mechanisms, detection and protection against phishing, authenticated vulnerability scanning, and enhanced script management for payment pages.

Merchant takeaway: If you handle card data in any form — even if your payment page redirects to a hosted checkout — your PCI compliance scope just expanded. The payment page script management requirement (Requirement 6.4.3) means you must inventory and authorize all scripts executing on your payment pages, and monitor them for tampering. If you use a third-party checkout, confirm with your provider that they are compliant and understand which requirements remain your responsibility. Your next PCI assessment will evaluate these requirements as mandatory, not optional. (See Chapter 24 for a comprehensive guide to PCI DSS and what it means for your business.)

Practitioner takeaway: Three requirements demand architectural attention. First, Requirement 6.4.3 (payment page script integrity) requires a mechanism to inventory, authorize, and monitor all JavaScript executing on payment pages — Content Security Policy plus Subresource Integrity is a common approach, but it needs active management, not just initial setup. Second, Requirement 11.6.1 requires change-and-tamper detection for HTTP headers and payment page content — build monitoring that alerts on unexpected changes. Third, Requirement 12.3.1 requires targeted risk analysis to justify the frequency of any control not performed at a fixed interval — document your rationale for how often you rotate keys, scan for vulnerabilities, and review access logs. The era of "check the box annually" is over; PCI v4.x requires continuous, evidence-based security.

Timeline summary of all 20 entries, August 2023 through April 2026. Categories indicate the primary type of change; regions indicate primary geographic scope. Many changes — particularly standards migrations like ISO 20022 — have global implications even when initiated by a single jurisdiction.

Diagram 2: Key upcoming deadlines from 2026 to 2030. Milestones marked "(uncertain)" reflect regulatory timelines that have been stayed or are under reconsideration. Plan for the requirement even if the enforcement date shifts.

May 2025 — UK CHAPS Mandates Purpose Codes for Property Payments

Who: Bank of England

Starting May 2025, all CHAPS payments related to property transactions must carry structured purpose codes and Legal Entity Identifiers (LEIs). Purpose codes are standardized labels that tell the receiving bank why the payment was sent — "property purchase," "deposit," "stamp duty," and so on. LEIs are 20-character codes that uniquely identify the legal entities in the transaction, replacing free-text name fields that are easy to spoof.

This is phase one. The Bank of England plans to extend purpose codes and LEIs to all CHAPS payments by November 2027 (see the September 2025 entry below).

Merchant takeaway: If you operate in UK property — estate agencies, conveyancers, or any business that handles property-related CHAPS payments — you need to include structured purpose codes in your payment instructions starting May 2025. This is not optional. For merchants outside property, this does not affect you yet, but it previews what is coming for all CHAPS payments by 2027. Start planning now. (See Chapter 18 for how bank transfer rails work.)

Practitioner takeaway: Purpose codes and LEIs mean your payment instruction templates need new mandatory fields. If you build payment initiation software that generates CHAPS messages, update your schemas to include ISO 20022 purpose codes (from the External Purpose Code list) and LEI fields. Validate both before submission — CHAPS will reject payments missing required codes for property transactions. The broader lesson: ISO 20022's structured data fields are moving from "nice to have" to "mandatory."

June 2025 — FATF Updates Recommendation 16 (The Travel Rule)

Who: Financial Action Task Force (FATF)

On 18 June 2025, the FATF published its updated Recommendation 16, extending the "travel rule" to cover virtual asset transfers alongside traditional wire transfers. The travel rule requires financial institutions to collect, hold, and transmit originator and beneficiary information with every transfer. The update harmonizes requirements across fiat and crypto rails — meaning a USDC transfer must now carry the same identity data as a SWIFT wire. Full compliance is expected by end of 2030, but early movers are implementing now.

Merchant takeaway: If you accept cryptocurrency payments or use stablecoins for cross-border settlement, your payment providers will start requiring more identity data per transaction. This is the FATF closing the gap between crypto and traditional payments — the same "know your counterparty" rules that apply to bank wires now apply to on-chain transfers. Expect your crypto payment processor to request additional sender/receiver information during onboarding and for each transaction. (See Chapter 26 for how stablecoins fit into payment flows.)

Practitioner takeaway: The updated R16 means your virtual asset transfer workflows need the same originator/beneficiary data fields as SWIFT messages: name, account number (or wallet address), address or national ID, and institution identifiers. If you build cross-border payment or stablecoin settlement systems, implement the travel rule data schema now — do not wait for 2030. The FATF explicitly noted that jurisdictions should not allow "sunrise issues" where one side of a transfer meets the rule and the other does not. Design for bilateral compliance from the start.

July 2025 — Fedwire Retires Legacy Format; ISO 20022 Fully Operational

Who: Federal Reserve Banks

On 14 July 2025, the Federal Reserve retired the Fedwire Application Interface Manual (FAIM) format — the legacy proprietary message format that had been used for Fedwire Funds Service transactions. From this date, all Fedwire messages use ISO 20022 (MX format) exclusively. The retirement was originally scheduled for March 2025 but was postponed to give participants more implementation time.

Merchant takeaway: Like the CHIPS migration in April 2024, most merchants do not interact with Fedwire directly — it is a wholesale and interbank system. But the ripple effects reach you through richer remittance data. If you receive large-value US dollar payments (supplier settlements, wholesale transactions, or treasury transfers), your bank statements and reconciliation files will carry more structured information: purpose codes, structured addresses, and detailed remittance data. Talk to your bank about when they will pass this enhanced data through to your accounts.

Practitioner takeaway: With both CHIPS (April 2024) and Fedwire (July 2025) now on ISO 20022, the two pillars of US dollar large-value payments speak the same structured language. If you build treasury, reconciliation, or settlement systems that consume data from either rail, standardize on a single MX parser. The delayed retirement date is also instructive: even the Fed needed more time than planned for migration. Budget generously for your own ISO 20022 transitions.

September 2025 — UK Announces "Data-Rich CHAPS" Expansion to All Payments

Who: Bank of England

Following the May 2025 property mandate, the Bank of England confirmed in September 2025 that purpose codes and enhanced data requirements will extend to all CHAPS payments by November 2027. The roadmap envisions CHAPS as a "data-rich" payment rail where every transaction carries structured purpose codes, LEIs, and enhanced remittance information — transforming CHAPS from a blunt pipe that moves money into an information-rich channel that tells both sides why the money moved.

Merchant takeaway: By November 2027, every CHAPS payment you send or receive will need structured purpose codes. This affects treasury operations, supplier payments, payroll funding, and any high-value sterling transfer. Start auditing your CHAPS payment flows now: which payments do you send, and what purpose codes will they need? If you rely on a bank or payment provider to generate CHAPS instructions, confirm their roadmap for supporting the new fields.

Practitioner takeaway: "Data-rich CHAPS" is the clearest example of a theme running through this entire chapter: payment rails are becoming data products. Your CHAPS integration layer needs to evolve from "amount + account" to "amount + account + purpose + entity + remittance context." Design your payment message schemas with extensibility in mind — the mandatory fields will keep growing. The November 2027 deadline gives you two years from the announcement, which sounds generous until you factor in testing, bank certification, and the inevitable edge cases.

October 2025 — FedNow Raises Transaction Limit to $10 Million

Who: Federal Reserve Banks

In October 2025, the Federal Reserve announced it was raising the FedNow transaction limit from $1 million to $10 million, effective 12 November 2025. Liquidity management transfers — used by banks to move funds between their Fed accounts — also increased from $2.5 million to $10 million. The increase was designed to make FedNow viable for a wider range of business payments, moving it beyond consumer and small-business use cases into mid-market B2B territory.

Merchant takeaway: If you are a larger merchant or B2B operator that has been constrained by FedNow's $1 million cap, the $10 million limit opens real-time settlement for transactions that previously required Fedwire. Real-time, 24/7/365 availability plus a $10 million ceiling means supplier payments, wholesale orders, and large invoice settlements can now flow through FedNow — with instant finality and no weekend delays. Ask your bank about FedNow access for high-value payments.

Practitioner takeaway: The 10x limit increase changes FedNow's competitive positioning against Fedwire for same-day and next-day high-value payments. If you build payment routing logic, update your rail-selection rules: payments under $10 million that need instant settlement can now route to FedNow instead of Fedwire, potentially at lower cost and with 24/7 availability. But watch for participant-level limits — individual banks may set their own caps below the system maximum. Query your FedNow participant directory for each counterparty's actual limit.

October 2025 — Fedwire Announces Weekend and Holiday Expansion

Who: Federal Reserve Banks

In October 2025, the Federal Reserve announced plans to extend Fedwire Funds Service operating hours to include Sundays and weekday holidays, targeting implementation in 2028 or 2029. Currently, Fedwire operates approximately 22 hours per day, Monday through Friday (excluding holidays). The expansion would make Fedwire available approximately 22 hours per day, six or seven days per week — a significant step toward "always-on" wholesale payments. Participation in extended hours is voluntary.

Merchant takeaway: For most merchants, this is background infrastructure — you do not interact with Fedwire directly. But it means your bank can settle and fund your accounts on days that are currently dead zones. Weekend and holiday settlement reduces float, speeds up cash availability, and eliminates the "Friday afternoon payment that does not arrive until Monday" problem for high-value transactions. The timeline is 2028–2029, so plan accordingly.

Practitioner takeaway: Weekend Fedwire has major implications for treasury and liquidity management systems. If your architecture assumes "no Fedwire on weekends," you have two to three years to update batch schedules, reconciliation windows, and liquidity buffers. The voluntary participation model means some counterparties will be available on Sundays and others will not — your payment routing and retry logic needs to handle mixed availability gracefully. This is the same "always-on" pattern we see in FedNow and CHAPS — large-value rails are converging toward 24/7 operation.

October 2025 — Singapore Launches BLOOM for Cross-Border Settlements

Who: Monetary Authority of Singapore (MAS)

On 16 October 2025, the MAS launched BLOOM — Borderless, Liquid, Open, Online, Multi-currency — a cross-border settlement platform built on tokenized digital liabilities and regulated stablecoins. BLOOM enables participating financial institutions to settle cross-border payments using tokenized commercial bank money and MAS-regulated stablecoins, bypassing the correspondent banking chain for participating currencies. The platform is designed to reduce settlement times from days to seconds for cross-border transactions between participating jurisdictions.

Merchant takeaway: If you operate cross-border in Southeast Asia or trade with Singapore-based counterparties, BLOOM could eventually offer faster and cheaper settlement than traditional correspondent banking. The platform is in its early stages, but it represents the direction of travel: central banks building infrastructure that competes with SWIFT for cross-border payments. Ask your bank whether they are a BLOOM participant and what currencies are supported. (See Chapter 27 for how blockchain and tokenization are being applied to payments.)

Practitioner takeaway: BLOOM is architecturally significant because it uses tokenized settlement — digital representations of commercial bank money that settle atomically on a shared ledger. If you design cross-border payment systems, study BLOOM's settlement model as a template for how tokenized money might replace nostro/vostro account pre-funding. Key design questions: how does your system handle tokenized settlement finality? How do you reconcile on-ledger and off-ledger positions? BLOOM provides early answers to these questions in a production environment.

November 2025 — SWIFT Ends MT/MX Coexistence for Cross-Border Payments

Who: SWIFT

On 22 November 2025, SWIFT ended the coexistence period for legacy MT payment messages and ISO 20022 MX messages on the Cross-Border Payments and Reporting Plus (CBPR+) platform. From this date, MT103 (customer credit transfers) and MT202 (financial institution transfers) can no longer be sent as native MT messages on CBPR+. SWIFT will continue to provide contingency translation services for institutions that are not yet fully migrated, but starting 1 January 2026, both the contingency service and in-flow translation for payment instructions become chargeable.

Merchant takeaway: You will not notice this change directly — it happens in the messaging layer between banks. But the consequence is cleaner, richer data in your cross-border payment confirmations and remittance information. If you have been frustrated by truncated or garbled payment references on international wires, the ISO 20022 migration is the fix. Ask your bank when you will start seeing enhanced remittance data in your account statements.

Practitioner takeaway: If your systems still generate or consume MT payment messages for cross-border flows, the free ride ended on 22 November 2025, and it becomes a paid service from 1 January 2026. Migrate to native MX message generation and parsing. Beyond the cost incentive, MX messages carry structured data that MT messages simply cannot — longer reference fields, structured addresses, purpose codes, and LEIs. The entire industry has moved; do not be the last to follow. The translation charges are a deliberate incentive to complete migration, not a long-term accommodation.

February 2026 — UK Announces CHAPS Early-Morning Settlement Extension

Who: Bank of England

The Bank of England confirmed plans to extend CHAPS settlement hours, moving the opening time from 06:00 to 01:30 UK time, with a target implementation date of September 2027. The extension enables early-morning settlement for time-sensitive payments — particularly relevant for Asian and Middle Eastern counterparties whose business hours overlap with the UK's early morning. Participation in the extended hours is optional for CHAPS direct participants.

Merchant takeaway: If you receive sterling payments from Asia-Pacific or Middle Eastern counterparties, the 01:30 start time means your funds can settle hours earlier — before the London business day even begins. This reduces the "overnight gap" where sterling payments queue up waiting for CHAPS to open. For domestic merchants, the impact is minimal unless you handle time-sensitive treasury operations. The September 2027 target gives you time to plan.

Practitioner takeaway: Early-morning CHAPS means your settlement monitoring, liquidity management, and funding processes need to start earlier. If your operations team begins at 08:00, the first six and a half hours of CHAPS activity happen without human oversight — which means your automated monitoring and alerting must be robust enough to handle exceptions autonomously. Design for lights-out processing during the 01:30–06:00 window. And with CHAPS joining FedNow and SEPA Instant in extending operating hours, the global trend toward "always-on" settlement is accelerating.

April 2026 — CFPB Rule 1033 Largest-Provider Deadline (Status: Uncertain)

Who: Consumer Financial Protection Bureau (CFPB)

The original compliance deadline for the largest financial data holders under CFPB Rule 1033 — the "Personal Financial Data Rights" rule — was 1 April 2026. However, the rule's implementation timeline was stayed by court order, and the CFPB initiated a reconsideration process in August 2025. As of early 2026, the final compliance dates remain uncertain. The rule itself has not been withdrawn — its core requirement for structured API-based access to consumer financial data remains intact — but the enforcement timeline has slipped.

Merchant takeaway: If you were planning to build consumer-facing financial data features (account aggregation, transaction insights, or financial health tools) relying on Rule 1033's API mandates, do not assume the April 2026 deadline will hold. Continue building toward structured API access — it is the direction of travel regardless of regulatory timing — but plan for a scenario where screen-scraping coexists with API access for longer than originally expected. (See the October 2024 entry for the rule's original scope.)

Practitioner takeaway: The Rule 1033 saga illustrates a pattern that applies beyond US open banking: regulatory timelines in payments are aspirational until they are not. Design your systems for the eventual requirement (structured, OAuth-based API access to consumer data) but build in flexibility for delayed enforcement. If you are a data aggregator, maintain both legacy screen-scraping and modern API access paths — the transition period just got longer. The FDX (Financial Data Exchange) standard remains the likely technical specification regardless of regulatory timing.

Patterns Emerging from the Log

Step back from the individual entries and five cross-cutting themes emerge. These are not predictions — they are patterns already visible in the changes above.

Pattern 1: "Always-On" Is Moving Up the Stack

FedNow already runs 24/7/365. SEPA Instant mandates 24/7/365 availability by October 2025. CHAPS is extending to 01:30 starts. Fedwire is planning weekend and holiday operations for 2028–2029. The direction is unmistakable: large-value and real-time rails are converging toward continuous operation.

This matters because "always-on" does not just mean the rail is available — it means your monitoring, reconciliation, liquidity management, and exception handling must also be always-on. The settlement system that closes at 5 PM on Friday and reopens Monday morning is disappearing. Every layer of the stack above the rail — from your treasury operations to your customer-facing payment status pages — needs to match the rail's availability.

Pattern 2: Payments Are Becoming Data Products

CHIPS migrated to ISO 20022. Fedwire followed. SWIFT ended MT coexistence. CHAPS is mandating purpose codes and LEIs. FATF's updated Recommendation 16 requires identity data on crypto transfers. In every case, the change is the same: payment messages must carry more structured data.

This is not a formatting exercise. When every payment carries purpose codes, entity identifiers, and structured remittance information, the payment itself becomes a data product. Reconciliation becomes automated. Fraud detection becomes richer. Compliance reporting becomes a byproduct of the payment flow rather than a separate process. The organizations that treat ISO 20022 as "a format migration" will miss the strategic opportunity; the ones that build on the richer data will gain operational advantages that compound over time.

Pattern 3: Fraud Control Is Shifting to Codified Incentives

The UK's APP scam mandatory reimbursement did something that guidance and voluntary codes could not: it put a price tag on fraud for both sending and receiving institutions. The 50/50 liability split means both sides of a push payment have financial skin in the game. FATF's travel rule update extends identity requirements to crypto transfers. The EU's Verification of Payee mandates pre-payment name matching.

The pattern is consistent: regulators are moving from "tell institutions to try harder" to "make it economically irrational not to prevent fraud." This changes the ROI calculation for every fraud prevention investment. When receiving institutions share liability for inbound scam payments, suddenly inbound fraud scoring — historically neglected — becomes a line item with measurable financial impact.

Pattern 4: Security Baselines Keep Ratcheting Upward

PCI DSS v4.x made 51 previously optional requirements mandatory. DORA imposed comprehensive operational resilience obligations across EU financial entities — including their cloud and SaaS providers. These are not aspirational guidelines; they are mandatory baselines with audit consequences.

The ratchet only turns one way. No standards body has ever lowered its security baseline. Every mandatory requirement creates a new floor that the next revision will build upon. If your compliance strategy is "meet the minimum," you are perpetually sprinting to keep up. The alternative — building security capabilities that exceed current requirements — creates a buffer that absorbs future mandates without emergency remediation.

Pattern 5: Competition Law Is Changing Acceptance Surfaces

Apple opening NFC access in the EEA was not a payments regulation — it was an antitrust remedy. But its effect on the payments ecosystem is profound: it broke a hardware-level monopoly on contactless payment initiation. Where only Apple Pay could trigger iPhone NFC payments, now any wallet can.

This entry stands alone in the timeline, but it represents a broader trend. The EU's Digital Markets Act, ongoing investigations into app store payment mandates, and scrutiny of payment platform fees all point to the same direction: competition regulators — not just payments regulators — are reshaping the acceptance surface. If your business model depends on a platform gatekeeper's exclusive access to a payment channel, that access is less durable than it once was.

Table 3: Five cross-cutting patterns mapped to timeline entries. These patterns tell you where the industry is heading, not just where it has been.

What to Do About It

Knowing what changed is step one. Knowing what to do about it is the part that matters. Here are actionable checklists for three reader types — run through yours quarterly, ideally timed to the start of each calendar quarter.

If You Are a Merchant

Your payments stack sits on top of rails, schemes, and standards that are shifting underneath you. The changes above affect your conversion rates, fraud exposure, reconciliation accuracy, and payout timing — even if you never touch the underlying infrastructure directly.

Quarterly review checklist:

• Review your 3DS and authentication configurations against the latest scheme mandates — exemption thresholds and SCA rules change without announcement
• Confirm your PCI scope is current — if you added a new payment page, widget, or third-party script since last quarter, your scope may have expanded
• Check your payout timing against rail changes — new settlement windows, instant payment mandates, and operating-hour extensions may allow you to get paid faster
• Verify that your payment provider is tracking the regulatory changes relevant to your geography — ask them which changes from this log they have implemented
• If you operate in the UK, confirm your CHAPS payments carry the required purpose codes (property transactions now; all transactions by November 2027)

If You Are New to Payments

The change log can feel overwhelming when you are still learning the basics. Here is how to use it as a learning accelerator rather than a source of anxiety.

Your task: For every payment method you accept or plan to accept, map it to four things:

1. Which rail carries it — card network, ACH, SEPA, Faster Payments, FedNow, etc.
2. Which scheme rules govern it — Visa Core Rules, Mastercard Standards, FPS rules, etc.
3. What data the rail requires — message formats, mandatory fields, identity requirements
4. Who bears liability when something goes wrong — chargeback rules, fraud liability, reimbursement obligations

Then scan this change log for entries that affect any of those four dimensions. You will find that every entry maps to at least one. This framework turns a list of 20 changes into a structured view of how the payments landscape is evolving around the methods you care about.

If You Are a Payments Professional

You already understand the infrastructure. The question for you is not "what changed" but "what do I need to re-validate in my systems?"

Quarterly re-validation checklist:

• Treat 2026–2029 as the window when "data-rich" and "always-on" become table stakes — if your systems are not designed for structured data and 24/7 operation, start the architecture work now
• Review your ISO 20022 implementation against the latest mandates — are you generating and consuming the full set of mandatory fields, or just the minimum subset?
• Audit your fraud detection pipeline for bidirectional coverage — outbound fraud scoring is standard, but inbound fraud scoring (APP scam liability, receiving-side risk) is now financially material
• Test your failover and operational resilience against DORA requirements — if you operate in the EU, your critical third-party providers must also demonstrate resilience
• Check your regulatory calendar — phased mandates (SEPA Instant, CHAPS data-rich, Rule 1033) have different deadlines for different participant types

Table 4: Quarterly review checklist by role. Each cell represents the highest-priority action for that quarter. Adapt the cadence to your organization's planning cycle — the point is regularity, not rigid timing.

How This Log Will Be Maintained

A change log is only useful if it stays current. Here is how this one will be updated.

Sources: Every entry is drawn from primary sources — official publications from regulators, scheme operators, and standards bodies. We never treat secondary news coverage as primary evidence. When a journalist reports a change, we go to the source document before adding it here.

Entry criteria: The five significance tests above are the admission filter. A change must pass at least two tests to be included. This keeps the log focused on operationally meaningful changes rather than every press release and consultation paper.

Update method: New entries are added chronologically with the same format: bold date and headline, entity identification, merchant takeaway, and practitioner takeaway. The summary table (Table 2) and pattern analysis (the Patterns section) are updated to reflect new entries. When an entry references a future deadline and that deadline arrives, the entry is updated with the outcome.

Frequency: The log is reviewed quarterly, aligned with the quarterly review checklist above. Between quarterly reviews, significant changes are added as they are confirmed — "confirmed" meaning the primary source is published, not just rumored.

What Comes Next

This chapter told you what is changing. It gave you dates, entities, and operational implications. But a change log, no matter how thorough, cannot replace the tools you need to respond.

That is what Chapter 41 provides. The Reference Library is a curated collection of the primary sources, tools, and frameworks that payments practitioners rely on — the documents you actually open when a change from this log hits your desk. Where this chapter is a record of what happened, the next chapter is your toolkit for what to do about it.

The change log tells you what changed. The reference library gives you the tools to respond.

Sources

• Monetary Authority of Singapore, "MAS Finalises Stablecoin Regulatory Framework," August 2023
• European Parliament and Council, Regulation (EU) 2024/886 (Instant Payments Regulation), March 2024
• The Clearing House, "CHIPS Completes Migration to ISO 20022," April 2024
• European Parliament and Council, Regulation (EU) 2024/1620 (AMLA Regulation), June 2024
• European Parliament and Council, Regulation (EU) 2023/1114 (MiCA), applicable June–December 2024
• European Commission, "Antitrust: Commission accepts Apple's commitments on NFC access," July 2024
• UK Payment Systems Regulator, "PS24/7: Mandatory reimbursement for APP scams," October 2024
• Consumer Financial Protection Bureau, "Personal Financial Data Rights Rule (Section 1033)," October 2024
• European Parliament and Council, Regulation (EU) 2022/2554 (DORA), applicable January 2025
• PCI Security Standards Council, "PCI DSS v4.0.1 — Future-Dated Requirements," effective March 2025
• Bank of England, "CHAPS Purpose Codes and LEI Requirements," May 2025
• FATF, "Updated Recommendation 16 — Wire Transfers and Virtual Asset Transfers," June 2025
• Federal Reserve Banks, "Fedwire Funds Service ISO 20022 Migration Complete," July 2025
• Bank of England, "CHAPS Enhanced Data Roadmap," September 2025
• Federal Reserve Banks, "FedNow Service — Transaction Limit Increase," November 2025
• Federal Reserve Banks, "Fedwire Funds Service Operating Hours Expansion," October 2025
• Monetary Authority of Singapore, "BLOOM — Cross-Border Settlement Platform Launch," October 2025
• SWIFT, "CBPR+ ISO 20022 — End of MT Coexistence," November 2025
• Bank of England, "CHAPS Settlement Hours Extension," February 2026
• Consumer Financial Protection Bureau, "Rule 1033 — Implementation Update," 2025–2026