What is CGI-MP and why does it matter for a new corporate API standard?

CGI-MP (Common Global Implementation, Market Practice) is a forum where banks, bank associations, corporates, corporate associations and market infrastructures agree common usage rules for ISO 20022 XML messages between corporates and banks (payment initiation, statements, confirmations), with SWIFT playing a support role. It exists specifically to reduce the cost corporates face supporting divergent bank-proprietary file formats. Any new commercial open finance API is arriving into a market where that standardization problem already has an incumbent answer.

How long does it actually take to migrate an entrenched corporate banking standard?

SWIFT's own MT-to-MX (ISO 20022) migration for cross-border payments is the clearest dated example. The coexistence period ran from 2023 with the core cutover in November 2025, and ancillary messages such as pain.002 and camt.029/055 were given until November 2027 under bilateral agreement. That is roughly four years of managed coexistence for one already-committed, single-organization-led migration, and a useful anchor for how long a voluntary new-standard adoption curve might realistically take across many banks and corporates.

Do APIs replace EBICS, BAI2, or SWIFT file exchange, or run alongside them?

In practice, the two run alongside each other, at least so far. Treasury-technology vendors consistently describe corporates running APIs, SWIFT messaging, host-to-host connections, and EBICS simultaneously, often per bank relationship, rather than treating APIs as a wholesale replacement. This is directional industry commentary rather than a measured statistic, but it points the same direction as the SWIFT migration timeline: coexistence, not fast displacement, is the realistic default.

Did PSD2 or UK Open Banking solve consent for corporate accounts with multiple signatories?

No, and this is documented, not inferred. Open Banking Limited's own Proposition P13 for "Multi-Authorisation for SME" states that roughly 665,400 UK Business Current Accounts (about 14% of all BCAs) require multi-party authorization, and that pre-P13, Open Banking APIs only supported single-party consent. The 2018 fix let a PISP initiate a multi-auth payment, but OBIE explicitly ruled standardizing the authorization workflow itself out of scope, describing complex business mandates as "the competitive space of the ASPSPs." Read-only account access was designed to never require multi-auth at all.

What does this mean for FDX or any standard building consent/entitlement for commercial accounts?

It's a visible failure mode to design around rather than discover later. PSD2's consent model was built around a single Payment Service User, and years after regulators tried to patch it, including through the PSD3/PSR reform, multi-signatory corporate authorization is still routed around the standard rather than handled inside it. It gets pushed into each bank's or TPP's proprietary tooling. A commercial/corporate open finance spec that leaves delegated authority, multi-party mandates, and entitlement management out of scope should expect the same outcome: workable point solutions, no interoperable standard.

Commercial Open Banking: ISO 20022, CGI-MP & the Corporate Consent Gap

Q: Does PSD3 or the Payment Services Regulation (PSR) close this gap?

Not as far as the published text and legal commentary show. EU negotiators reached provisional agreement on PSD3/PSR in November 2025, and COREPER endorsed the final texts in April 2026; entry into force is now expected around 2027, after formal adoption and a transition period. The reform's consent-related centerpiece is a mandatory "permission dashboard" letting a single user monitor and revoke third-party access, plus a 180-day re-authentication rule for account information access, and every law-firm summary of that dashboard describes it in single-user terms; none mention multi-party approval or delegated authority for business accounts. The legal definition of a Payment Service User already covers corporates, so that was never the missing piece. What's missing is a standardized way for multiple signatories to jointly authorize one consent grant, and PSD3/PSR does not appear to add one.

Retail open banking was largely greenfield. Most consumers had no standing machine-readable link to their bank before regulation created one. Commercial and corporate banking is not greenfield. Corporates already run on ISO 20022 messaging, CGI-MP usage conventions, EBICS file exchange, or BAI2 cash reporting. A new commercial API standard has to coexist with or displace infrastructure that already works. Separately, the consent model retail open banking shipped with was built for one person authorizing one connection, and it has never cleanly extended to accounts that need more than one signature.

Last reviewed: August 26, 2026

2023–2027

SWIFT's managed MT→MX (ISO 20022) coexistence window

Cross-border payments; ancillary messages extended to Nov 2027

~14%

UK Business Current Accounts requiring multi-signatory approval

OBIE Proposition P13

Out of scope

How OBIE classified standardizing multi-authorization workflows

Left to individual banks by design, 2018

Still out of scope

Whether PSD3/PSR (2026 reform) closes the gap

Permission dashboard is single-user; no multi-party provision found

What's already entrenched in corporate banking

Before any new API standard reaches a corporate treasury team, it's either competing with or plugging into infrastructure that's often decades old and still doing the job:

Standard	Role	Status
ISO 20022	Structured XML messaging standard for payments and cash reporting	Migrating from MT to MX; CBPR+ coexistence ran 2023–2025, some ancillary messages extended to 2027
CGI-MP	Common Global Implementation, Market Practice: bank/corporate forum agreeing ISO 20022 usage rules	Active; adoption skews toward payment initiation (pain.001) over balance reporting (camt.053)
EBICS	Electronic banking file-exchange protocol for corporate-to-bank connectivity	Standard in Germany (since 2008), France (2011), Switzerland (2015), Austria
BAI2	Bank Administration Institute cash-reporting file format (1980s)	Still the dominant US corporate cash-reporting format as of 2025, despite camt.053 being its designated successor

What migrating an entrenched standard actually costs: the SWIFT case

SWIFT's own MT-to-MX (ISO 20022) migration for cross-border payments is the cleanest dated data point available. Coexistence between the legacy MT format and the new ISO 20022 MX messages ran from 2023, with the core cutover in November 2025, after which MT payment messages (MT102/103/201/203) are rejected. Even then, ancillary messages like pain.002 and camt.029/055 were granted a bilateral extension to November 2027.

That's roughly four years of managed coexistence for a migration led by a single global cooperative with every incentive to move fast. A voluntary new commercial API standard, adopted bank-by-bank and corporate-by-corporate without that kind of central coordination, should be expected to take at least as long, likely longer.

The consent gap Europe never closed: multi-signatory accounts

PSD2's consent model was built around a single Payment Service User authorizing a single third party. UK Open Banking inherited that shape, and its own standards body documented the mismatch directly. Open Banking Limited's Proposition P13 ("Multi-Authorisation for SME") states that around 665,400 UK Business Current Accounts, roughly 14% of all BCAs, require more than one signature to authorize activity, and that before P13, Open Banking APIs only supported single-party consent at all.

The 2018 fix let a payment initiation provider kick off a multi-auth payment, but OBIE explicitly ruled standardizing the authorization workflow itself out of scope, calling complex business mandates "the competitive space of the ASPSPs." Read-only account access (AIS) was designed to never require multi-auth in the first place. In other words, the interoperable layer never carries multi-party corporate mandate logic. Every bank and TPP builds its own version, on top of the standard, not inside it.

Years later, that's still the state of play, with no evidence EU or UK bodies have gone back to standardize delegated or multi-party authority at the spec level: it got routed around, not resolved.

Nor does the EU's next payments reform close it. PSD3 and the accompanying Payment Services Regulation (PSR) reached provisional political agreement in November 2025, and COREPER endorsed the final texts in April 2026, with entry into force now expected around 2027. Its consent-related centerpiece is a mandatory "permission dashboard" that lets a user monitor and revoke third-party access, plus a 180-day re-authentication rule for account information, and every legal summary of that dashboard describes it in single-user terms; none mention multi-party approval or delegated authority for business accounts. A multi-year reform cycle had the opportunity to fix this and passed on it.

What this means for a new commercial open finance standard

Plan for coexistence, not replacement. ISO 20022/CGI-MP/EBICS/BAI2 aren't going away on the timeline a new API rollout plan might assume. Budget years, not quarters, for parallel running.
Design entitlement and delegation in from day one. PSD2's single-PSU model is the visible failure mode: leaving multi-signatory and delegated authority out of the interoperable layer just pushes it into proprietary, non-portable implementations later.
Corporate accounts aren't a retail account with a different label. Mandates, thresholds, and joint-approval workflows are core to how businesses actually authorize activity. Treating them as an edge case repeats the gap PSD2 left open.

Frequently asked questions

Retail open banking displaced very little. Most consumers had no standing machine-readable connection to their bank before PSD2 or the UK's CMA order. Commercial and corporate banking is different: treasury teams already run on ISO 20022 messaging, CGI-MP usage conventions, EBICS file exchange, or BAI2 cash reporting. A new API spec for corporates isn't filling a void. It's entering a market with working, entrenched infrastructure, and that changes both the adoption incentive and the realistic migration timeline.

Sources

Related resources

Open Banking Standards Fragmentation— PSD2 compliance vs interoperability, sourced Open Banking API Standards Explained— PSD2, FDX, Berlin Group and UK Open Banking compared Section 1033 Status & Timeline— Is the US open banking rule in effect?Open Banking Regulations— 58 jurisdictions, API specifications and timelines Open Banking Glossary— PSU, consent, TPP and other core terms defined

Commercial Open Banking Standards

Corporate banking isn't greenfield, and Europe never solved consent for accounts with more than one signatory. Two problems any new commercial spec should design around, not discover later.