The 2026 Global Payments Outlook: Operating Model, Risk, and Revenue in an Agentic, Invisible, Real-Time World

Payments have moved from an administrative utility to the core of bank technology strategy. In 2026 the global payments operating model is defined by three converging forces, agentic commerce, invisible embedded flows and real-time execution, and each reshapes where a transaction bank carries risk and earns revenue. This report synthesises the 2026 outlooks of J.P. Morgan Payments, Global Payments, HSBC and The Payments Association into a single operating-model view: how G-SIB and regional executives, treasury heads and regulators must navigate model-initiated commerce, always-on liquidity under DORA, tokenised unified ledgers under BIS Project Agorá, and the hard-dated November 2026 SWIFT structured-address cut-over.

Executive Summary

• Payments are now the operating core, not a utility. The 2026 to 2028 cycle is a structural window: technology, regulation and customer expectation have converged onto a single operating plane, and modern payment infrastructure is the foundation of bank-grade technology strategy.
• Agentic, invisible and real-time flows each move a different risk. Agentic commerce shifts liability and model-risk management; invisible embedded payments threaten disintermediation; real-time execution accelerates the velocity of capital and rewrites liquidity, credit and fraud control.
• Four pillars carry the capital and technology budget. Bounded-authority agentic API gates, always-on Treasury-as-a-Service under DORA, tokenised deposits on unified ledgers, and structured-data fraud defence are where allocation decisions determine the competitive landscape of transaction banking.
• The compliance clock is the forcing function. The 14 November 2026 structured-address cut-over is a no-regrets move; agentic safeguards and tokenisation are the strategic options layered on top across a three-horizon roadmap.

For global transaction banks, the 2026–2028 cycle represents a critical structural window. Modern payment infrastructure is no longer merely an administrative utility; it is the fundamental core of bank-grade technology strategy. The decision-makers within G-SIBs and major regional financial institutions face a highly complex landscape where technology, regulation, and customer expectations have converged into a single operating plane.

The three structural forces driving this cycle, agentic, invisible, and real-time payment flows, correlate directly with the core concerns of the executive suite:

• Agentic Commerce: Impacts channel distribution, product design, liability assignment, and Model Risk Management (MRM) under supervisory scrutiny.
• Invisible Payments: Redefines the customer experience, threatening disintermediation if banks fail to embed their ledgers directly into corporate and merchant front-ends.
• Real-Time Execution: Accelerates the velocity of capital, fundamentally changing liquidity management, credit risk, operational resilience, and fraud defense.

The financial and operational stakes of this transition are immense. As fraud techniques scale in speed and sophistication, and regulatory frameworks enforce strict compliance dates, transaction banks that pro-actively modernise their core systems can unlock substantial fee-revenue opportunities. Conversely, the cost of inaction is marked by immediate transaction rejections, operational bottlenecks, regulatory penalties, and rapid market-share erosion.

The Convergence of Global Payment Authorities #

To map the trajectory of this structural shift, this report synthesizes the 2026 payments and commerce outlooks published by four authoritative industry leaders: J.P. Morgan Payments, Global Payments, HSBC, and The Payments Association.

While each organisation approaches the payments ecosystem from a distinct market perspective, their findings converge on three invariant, industry-wide realities:

1. Instant, API-driven rails are the baseline. Legacy batch-processing models are rapidly being marginalised for cross-border and high-value flows; transaction velocity for those segments is increasingly dictated by always-on, real-time messaging.
2. AI acts as both a primary threat vector and the core defense mechanism. Generative tools and deepfakes are scaling transaction fraud, necessitating real-time, multi-layered machine learning counter-defenses.
3. Tokenisation is transitioning to production-ready infrastructure. Ledgers are unifying to support the co-existence of tokenised commercial liabilities and central bank digital currencies (CBDCs) for wholesale settlement.

These perspectives also sit within a broader public-sector agenda. Under the G20 Roadmap for Enhancing Cross-Border Payments, the Financial Stability Board has launched a new implementation phase that explicitly depends on closer public-private collaboration to deliver faster, cheaper and more transparent cross-border flows. The four outlooks from J.P. Morgan, Global Payments, HSBC and The Payments Association effectively define the private-sector operating stack that will run on top of this policy infrastructure, translating the G20 objectives into concrete decisions on liquidity, tokenisation, data and fraud controls inside banks.

These authorities collectively show that successful bank execution in the 2026–2028 cycle requires an integrated, multi-disciplinary approach. Each of the four pillars discussed below represents an allocation of capital, technology budget, and risk-management focus that will determine the competitive landscape of transaction banking for the next decade.

Pillar 1: Agentic Commerce and Invisible Payments #

Agentic commerce represents the transition from human-driven, click-to-buy digital checkout structures to autonomous, model-driven transaction initiation. Industry forecasts suggest that autonomous AI agents could mediate on the order of $3–$5 trillion in annual commerce by 2030, implying a low-single-digit share of global payment volumes transacted without a human explicitly clicking the 'buy' button.

This shift creates a profound gap in the retail and commercial ecosystem. While a clear majority of consumers now expect near-frictionless payments, less than half of merchants have fully prioritised one-click checkout or API-accessible product catalogues in their roadmaps. AI agents cannot navigate complex, legacy, multi-page checkout screens designed for human eyes; they require clean, structured, machine-to-machine API handshakes.

Bank Priorities and Operational Impacts #

For transaction banks, agentic commerce introduces a completely new set of risk and operational considerations:

• KYC and AML Ownership: Banks must define who holds the compliance obligation within an agentic transaction chain. If a consumer's personal AI agent initiates a transaction via a merchant's agentic checkout, the bank must be able to verify that the originating delegated authority is cryptographically bound to the primary account holder, ensuring compliance with anti-money laundering (AML) and know-your-customer (KYC) regulations.
• Liability and Chargeback Redesign: Traditional card schemes and Account-to-Account (A2A) payment rails rely on dispute frameworks designed for human authorisation. When an AI agent makes a suboptimal or erroneous purchase, such as procuring incorrect industrial inventory due to a data-parsing error, banks must establish clear legal and operational boundaries to allocate liability between the consumer, the agent provider, and the merchant.
• Risk-Rating Agentic Flows: Payment routing engines must dynamically risk-rate agentic payments, applying higher reserve requirements or interchange rates to non-human-initiated transactions until a track record of settlement stability is established.

Bounded Action and Bounded Authority Models #

To mitigate the systemic risk of "unbounded action" (e.g., an enterprise procurement agent executing infinite recursive purchase loops due to a software glitch), banks must deploy bounded-authority API gates. These gates restrict agent execution through multi-dimensional, policy-enforced limits:

1. Tiered Financial Limits: Restricting agent spending by transaction size, daily cumulative value, or merchant categories.
2. Context-Aware Safeguards: Evaluating secondary signals such as time-of-day, IP geolocation, and transaction frequency before releasing ledger funds.
3. Human-in-the-Loop (HITL) Escalation: Triggering a mandatory human authorisation prompt via Strong Customer Authentication (SCA) under PSD3/PSR regulations whenever a transaction exceeds designated risk thresholds.

The following Mermaid sequence diagram illustrates a secure, bounded-authority agentic payment flow that many banks will recognise as a target architecture.

sequenceDiagram
    autonumber
    actor User as Treasurer / Customer
    participant Agent as Autonomous AI Agent
    participant BankAPI as Bank API Gateway (MCP Server)
    participant Policy as OPA Policy Engine
    participant Ledger as Core Banking Ledger
    User->>Agent: Provisions Bounded Authority (Spend limit $5k, Vendor Category: Cloud Services)
    Agent->>BankAPI: Requests Payment Initiation (signed token, credentials)
    Note over BankAPI: Active-active cloud gateways check credentials
    BankAPI->>Policy: Forwards Request for Compliance Evaluation
    Note over Policy: Evaluates: Spending limit < $5k?<br/>Geographic IP valid?<br/>Is recipient in approved whitelist?
    alt Policy Evaluation Passes
        Policy-->>BankAPI: Policy Validated (Approved)
        BankAPI->>Ledger: Instructs instant A2A settlement via FedNow/SEPA Inst
        Ledger-->>BankAPI: Settlement Confirmed (Transaction ID)
        BankAPI-->>Agent: Dispatches Payment Confirmation (XML pain.002)
    else Policy Evaluation Fails (Risk Limit Exceeded)
        Policy-->>BankAPI: Risk Threshold Breached (Trigger SCA Escalation)
        BankAPI->>User: Initiates Strong Customer Authentication (FIDO2 Passkey challenge)
        User-->>BankAPI: SCA Signature Verified
        BankAPI->>Ledger: Instructs instant A2A settlement
        Ledger-->>BankAPI: Settlement Confirmed
        BankAPI-->>Agent: Dispatches Payment Confirmation
    end

The Role of the Model Context Protocol (MCP) #

To connect localised AI models to bank-governed execution layers, the industry is standardising around the Model Context Protocol (MCP), an open protocol that lets LLMs call clearly scoped, auditable tools and APIs without direct access to core systems, so banks can strictly control how models initiate payments or queries.

By wrapping banking APIs (such as payment initiation or balance inquiries) inside an MCP server, banks can ensure that LLMs do not have direct, raw access to database tables or system root controls. Instead, the model can only interact with the ledger through heavily structured, audited, and rate-limited API endpoints, ensuring absolute security at the boundary of agentic tool execution.

Pillar 2: Treasury Transformation and Liquidity Reimagined #

The velocity of transaction banking in 2026 is driven by the shift from legacy, end-of-day batch processing to always-on, real-time treasury operations. Multinational corporations no longer tolerate "trapped cash", liquidity sitting idle in local accounts over weekends or holidays due to settlement system closures.

The Economic Justification for Real-Time Liquidity #

J.P. Morgan and HSBC both highlight that corporates with advanced, real-time cash and data capabilities are significantly more likely to outperform peers on revenue growth and capital efficiency, largely by reducing trapped liquidity and optimising working-capital cycles.

To capture this value, banks are delivering Treasury-as-a-Service (TaaS) API products, allowing corporate Enterprise Resource Planning (ERP) systems (such as SAP and Oracle) to connect directly to the bank's ledger:

• Real-Time Balance APIs (using camt.052 schema): Replaces file-transfer protocols with instant, event-driven cash position reporting.
• Bulk Payment Initiation APIs (using pain.001 schema): Enables direct, straight-through execution of vendor payment batches directly from ERP ledgers.
• Continuous FX APIs: Allows treasury engines to lock in real-time, algorithmic foreign exchange rates for cross-border settlement, eliminating overnight market-gap risk.
• Virtual Account APIs: Enables corporations to dynamically spin up and retire thousands of sub-accounts for automated, instant receivables matching and ledger separation.

Operational Resilience and DORA Implications #

For transaction banks, offering always-on liquidity services transforms the risk profile of the core banking system. Always-on platforms must maintain 99.999% operational availability while subjected to continuous, real-time transaction loads.

Under the Digital Operational Resilience Act (DORA), this is not merely an IT performance goal, it is a strict regulatory compliance requirement. Regulators expect banks to prove that their real-time treasury APIs and ledger databases can absorb severe but plausible cyberattacks, network outages, and hyperscaler disruptions without interrupting critical payments or compromising systemic liquidity. This requires transaction banking heads to invest heavily in geo-redundant, active-active multi-cloud database architectures, real-time threat-detection layers, and automated failover systems.

Continuous FX and Cross-Border Innovation #

The real-time treasury cannot operate within a single currency boundary. To support global corporate flows, G-SIBs are deploying continuous FX infrastructure, such as J.P. Morgan's Wire 365 platform, which enables eligible clients to process cross-border payments and FX conversions any day of the year, including weekends and holidays, beyond traditional Central Bank Real-Time Gross Settlement (RTGS) operating hours. This framework interlocks directly with the tokenised deposit and unified ledger systems discussed in Pillar 3.

Pillar 3: Tokenised Deposits and Unified Ledger #

Tokenisation has graduated from isolated, proof-of-concept blockchain pilots to scaled, bank-grade monetary infrastructure. The focus has shifted from private stablecoins and speculative cryptoassets to tokenised commercial bank deposits and wholesale Central Bank Digital Currencies (wCBDCs) operating on programmable, unified ledgers.

The reference framework for this next-generation monetary system is Project Agorá, a major public-private collaboration convened by the Bank for International Settlements (BIS) and the Institute of International Finance (IIF), involving seven central banks and over 40 private financial institutions. Project Agorá: An international project investigating how tokenised commercial bank deposits can be seamlessly integrated with tokenised wholesale Central Bank Digital Currencies (wCBDCs) on a shared, programmable, unified ledger to eliminate cross-border settlement friction, coordinate compliance checks, and enable 24/7 atomic transaction finality for cross-border payments.

The Five-Step Tokenisation Journey #

For G-SIBs and major regional transaction banks, implementing tokenisation is a highly structured, stepwise journey that moves from internal optimisation to open market interoperability:

1. Internal Treasury Liquidity: Tokenising internal corporate cash balances (e.g., JPM Coin or equivalent private bank ledgers) to enable instant, 24/7 cross-border transfers and netting across the bank's own branches.
2. Bounded Multi-Bank Corridors: Participating in closed, regulated consortia (such as the Project Agorá sandbox) to test interbank settlement and shared ledger state across distinct institutions.
3. Continuous Programmable FX: Leveraging smart contracts on unified ledgers to execute instant, automated Payment-versus-Payment (PvP) foreign exchange transactions, eliminating settlement risk across time zones.
4. Tokenised Real-World Assets (RWAs): Integrating the tokenised cash leg with tokenised security, debt, or trade ledgers to enable instant Delivery-versus-Payment (DvP) finality, reducing capital lockup from days to milliseconds.
5. Public/Regulated Hybrid Interoperability: Establishing secure, regulated gateway wrappers to allow institutional liquidity to interact safely with open decentralised public networks.

Prudential and Balance Sheet Implications #

The transition to tokenised cash requires careful navigation of prudential banking frameworks. Regulators and supervisors emphasise that a tokenised deposit must be economically equivalent to a traditional commercial bank deposit, meaning it represents an unsecured liability on the bank’s balance sheet and carries the same deposit insurance coverage.
However, from an operational and technological standpoint, tokenised deposits introduce unique risks. Smart contracts can execute automated, programmable withdrawals at speeds and volumes that traditional liquidity stress-testing models are not designed to simulate. Under Basel III capital requirements, banks must ensure their risk engines can model programmable cash run-offs and that their tokenised ledgers interoperate cleanly with legacy Real-Time Gross Settlement (RTGS) systems during daily liquidity cycles.

Stablecoins vs. Tokenised Deposits: A Nuanced Positioning #

While private, fully reserved stablecoins (such as USDC) continue to capture significant market share in retail cross-border remittances and decentralised commerce, they lack the credit-creation capacity and settlement finality of the commercial banking system.

Rather than competing directly on retail rails, transaction banks are establishing custody, issuing their own regulated tokenised liability instruments, and building secure on-/off-ramp gateways. This allows corporate clients to enjoy the programming flexibility of digital tokens while keeping their capital secured within the regulated banking perimeter.

Questions Boards Should Ask About Tokenised Money

• Unified Ledger Participation: What is our active strategic roadmap for participating in wholesale public-private unified ledger initiatives like Project Agorá?
• Balance Sheet & Risk Modeling: Have our risk engines and capital adequacy frameworks updated their stress-testing models to account for the speed of smart-contract-triggered token run-offs?
• First-Mover Client Segments: Which of our corporate treasury and commercial banking client segments would benefit immediately from programmable, tokenised DvP/PvP settlement?

Pillar 4: Structured Data and Fraud Defense #

Infrastructure compliance in 2026 is dominated by the November 14, 2026 structured address cut-over established under SWIFT Standards Release (SR) 2026. SWIFT SR 2026 structured address cut-over: From November 14, 2026, the SWIFT CBPR+ and SEPA payment networks will officially stop accepting fully unstructured, free-text postal address blocks (<AdrLine>) in payment messages. Any cross-border or domestic payment message carrying an unstructured address where structured elements are expected will be immediately delayed or rejected by the network.

Most financial institutions recognise the date, but many have treated it merely as a superficial mapping exercise at the interface level. In reality, the structured address mandate is a profound data-quality and data-governance challenge. To avoid catastrophic reject rates, payment operations must be reorganised under a clear, cross-functional data-governance framework:

• Product and Operations Teams: Responsible for data capture at the source. This includes updating customer-facing digital portals, onboarding interfaces, and corporate ERP input fields to enforce structured address fields (e.g., Street Name <StrtNm>, Post Code <PstCd>, Town Name <TwnNm>, Country <Ctry>) directly at the point of payment initiation.
• Technology Teams: Responsible for data parsing, mapping, and database schema validation. This includes deploying validation engines that block legacy files before they reach the SWIFT interface, and utilising localised machine learning models to parse legacy unstructured address blocks into XML-compliant tags under the <PstlAdr> parent node.
• Compliance and Risk Teams: Responsible for updating sanctions screening, transaction monitoring, and anti-money laundering (AML) screening logic to ingest the highly structured XML fields, significantly reducing false-positive rates and manual investigations.

The Business Case for Structured Data #

While often framed as a compliance cost, high-quality ISO 20022 payment data is a powerful revenue enabler for transaction banks:

1. Advanced Credit Decisioning: Structured invoice, remittance, and ultimate-debtor data allows banks to build automated, highly precise working-capital financing and supply-chain invoice factoring programs for corporate clients.
2. Automated Receivables Matching: Exposing structured party and invoice identifiers allows banks to offer premium cash-reconciliation and virtual-account pooling products, generating new transaction fee revenue.
3. Monetisable Transaction Analytics: Banks can package and sell granular, real-time liquidity and purchasing-pattern analytics dashboards directly to corporate CFOs and treasurers.

A Layered AI Fraud Defense Model #

As transaction speeds accelerate to real-time, fraud techniques have scaled in complexity. Recent research indicates that deepfakes now account for around 40% of biometric fraud attempts, with synthetic media increasingly used to defeat voice and facial-recognition controls in onboarding and payment flows.

To defend against always-on, high-velocity fraud vectors, transaction banks must deploy a Three-Layer AI Fraud Defense Model:

1. Identity Layer: Enforcing biometrically verified FIDO2 passkeys, cryptographically signed hardware device-binding, and decentralised digital ID wallets to secure payment access.
2. Behavioral Layer: Monitoring continuous behavioural biometrics, such as session navigation pacing, typing cadences, and device orientation, to detect automated bot execution or session-hijack attempts.
3. Transaction Layer: Leveraging the highly structured fields of ISO 20022 messages to feed real-time, machine-learning risk engines, cross-referencing transaction metadata with shared, network-level consortium intelligence to identify suspicious transactions within milliseconds of initiation.

To satisfy supervisory expectations, these transaction-layer AI models must incorporate strict explainability parameters and operate under a dedicated Model Risk Management (MRM) program. Regulators expect banks to be able to explain the specific data points and algorithmic logic that triggered an automated payment block or a fraud-related alert, in line with supervisory expectations such as US Federal Reserve SR 11-7 and the Bank of England's PRA SS1/23 Model Risk Management principles for banks.

2026–2028 Boardroom Agenda for Global Payments #

To successfully execute across these four pillars, G-SIB and regional bank management bodies should organise their operational and technology investments across a clear, three-horizon strategic roadmap:

Horizon 1: Immediate Compliance and Core Hardening (0–12 Months) #

• Focus: Standardise ISO 20022 Data Quality and secure basic real-time transaction paths.
• Success Indicator (KPI): Zero unstructured address rejections on SWIFT and SEPA networks post-November 14, 2026 standards release.
• Executive Owner: Chief Operating Officer (COO) / Head of Payment Operations.
• Deliverable Type: No-Regrets Move. Core database schema updates and SWIFT SR 2026 validation engine deployment.

Horizon 2: Automation and Agentic Safeguards (12–24 Months) #

• Focus: Deploy bounded agentic API gates and continuous fraud defense architectures.
• Success Indicator (KPI): 100% of machine-to-machine and AI-initiated API transactions validated through FIDO2 hardware binding and bounded-authority policy engines.
• Executive Owner: Chief Information Officer (CIO) / Chief Risk Officer (CRO).
• Deliverable Type: No-Regrets Move (Fraud Defense) and Strategic Option (Agentic Commerce). Implementation of the Model Context Protocol (MCP) and three-layer fraud AI.

Horizon 3: Platform Tokenisation and Unified Ledgers (24–36 Months) #

• Focus: Transition treasury assets to tokenised deposits and participate in shared cross-border ledgers.
• Success Indicator (KPI): At least 15% of high-value corporate treasury settlement volume processed natively via tokenised deposit instruments or unified ledger arrangements (e.g., Project Agorá corridors).
• Executive Owner: Group Treasurer / Head of Transaction Banking.
• Deliverable Type: Strategic Option. Deployment of programmable ledger infrastructure, smart-contract liquidity rules, and DvP/PvP settlement adapters.

Frequently Asked Questions #

Who owns KYC and AML when an autonomous agent initiates a payment? The originating bank still owns the obligation, but it must be able to prove that the agent's delegated authority is cryptographically bound to the primary account holder. In practice that means treating an agentic transaction chain as a new liability frontier: the bank verifies the delegation, applies bounded-authority limits at the API gate, and risk-rates non-human-initiated flows until a settlement track record exists. SCA delegation under PSD3/PSR governs when a human must be pulled back into the loop.

Why is always-on liquidity a DORA problem and not just an IT upgrade? Because offering 24/7 treasury APIs turns availability into a supervisory requirement rather than a service-level preference. A real-time ledger that must hold 99.999% availability under continuous transaction load has to demonstrate, to a regulator, that it survives severe-but-plausible cyberattacks, network outages and hyperscaler disruption without interrupting critical payments. That forces investment in geo-redundant, active-active multi-cloud architecture and automated failover, which is a resilience mandate, not a performance target.

How is a tokenised deposit different from a stablecoin on the balance sheet? A tokenised deposit is economically equivalent to a traditional commercial bank deposit: an unsecured liability on the bank's balance sheet carrying the same deposit-insurance treatment and credit-creation capacity. A stablecoin is a fully reserved instrument that lacks that credit-creation capacity and settlement finality. The operational difference is speed: smart contracts can trigger programmable run-offs faster than legacy liquidity stress models assume, so risk engines must model smart-contract-driven run-off under Basel III.

What actually happens on 14 November 2026 if address data is not structured? Under SWIFT SR 2026, CBPR+ and SEPA messages carrying unstructured free-text address blocks where structured elements are expected are delayed or rejected outright at the network level. It is a hard-dated cut-over, not a soft migration, so a bank that has treated it as an interface-mapping exercise rather than a data-governance programme faces immediate reject-rate spikes across product, technology and compliance. The remedy is structured capture at the point of initiation into the <PstlAdr> tags.

References #

• BIS Innovation Hub, (2026). Project Agorá: exploring tokenisation of wholesale cross-border payments [online]. Basel: Bank for International Settlements. Available at: BIS Project Agorá [Accessed 25 June 2026].
• Deutsche Bank, (2026). Digital Money: a perspective on stablecoins, tokenised deposits and CBDCs [online]. Frankfurt am Main: Deutsche Bank Flow. Available at: Deutsche Bank Digital Money [Accessed 25 June 2026].
• Digital Bank Expert, (2026). ISO 20022 Structured Addresses: 2026 Deadline [online]. London: Digital Bank Expert. Available at: Digital Bank Expert ISO 20022 [Accessed 25 June 2026].
• European Parliament and Council of the European Union, (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) [online]. Brussels: Official Journal of the European Union. Available at: DORA Regulation [Accessed 25 June 2026].
• European Banking Authority (EBA), (2019). Guidelines on outsourcing arrangements (EBA/GL/2019/02) [online]. Paris: EBA. Available at: EBA Outsourcing Guidelines [Accessed 25 June 2026].
• Financial Stability Board (FSB), (2026). FSB kicks off new implementation phase to enhance cross-border payments through public-private partnership [online]. Basel: FSB. Available at: FSB Cross-Border Payments [Accessed 25 June 2026].
• Global Payments, (2025). Global Payments Releases its 2026 Commerce and Payment Trends Report [online]. Atlanta: Global Payments Investor Relations. Available at: Global Payments Press Release [Accessed 25 June 2026].
• HSBC Business, (2026). HSBC Business Insights [online]. London: HSBC. Available at: HSBC Insights [Accessed 25 June 2026].
• J.P. Morgan Payments, (2026). Payments Outlook 2026 Trends Report Released [online]. New York: J.P. Morgan Payments Newsroom. Available at: J.P. Morgan Newsroom [Accessed 25 June 2026].
• J.P. Morgan Insights, (2026). 5 Payment Trends to Watch for in 2026 [online]. New York: J.P. Morgan Insights. Available at: J.P. Morgan Trends [Accessed 25 June 2026].
• SWIFT, (2026). ISO 20022 milestone for November 2026: Unstructured addresses to be removed [online]. La Hulpe: SWIFT News. Available at: SWIFT ISO 20022 Milestone [Accessed 25 June 2026].
• SWIFT Standards, (2026). Removal of unstructured address [online]. La Hulpe: SWIFT Standards. Available at: SWIFT Unstructured Address Removal [Accessed 25 June 2026].
• Bank of England, (2023). Supervisory Statement (SS1/23): Model risk management principles for banks [online]. London: Bank of England. Available at: Bank of England PRA SS1/23 [Accessed 25 June 2026].
• Bright Defense, (2026). Deepfake Statistics: A Growing Security Concern [online]. Atlanta: Bright Defense. Available at: Deepfake Fraud Statistics [Accessed 25 June 2026].
• Federal Reserve Board, (2011). Supervisory Guidance on Model Risk Management (SR 11-7) [online]. Washington, D.C.: Board of Governors of the Federal Reserve System. Available at: Supervisory Guidance on Model Risk Management [Accessed 25 June 2026].
• McKinsey & Company, (2025). McKinsey Forecast: $5 Trillion in Agentic Commerce Sales by 2030 [online]. Chicago: Digital Commerce 360. Available at: McKinsey Agentic Commerce Forecast [Accessed 25 June 2026].
• J.P. Morgan FX & Cross-Border, (2026). Wire 365: Global Clearing Reinvented [online]. New York: J.P. Morgan Payments. Available at: J.P. Morgan FX Wire 365 [Accessed 25 June 2026].

Last reviewed 2026-07-25.