55 APIs. One gateway.
Every rail in global finance, wired into iBANK.

iREF is the network's reference-data lookup service, giving institutions an automated way to enrich and validate payment data before it's sent. It covers enrichment (attaching ISO 20022 postal addresses, payment-market-infrastructure participation, and Standing Settlement Instructions to a payment), mapping (converting between BICs, national IDs, and LEIs), deriving details from an IBAN, and pulling participant lists for efficient payment routing. Data refreshes daily, which is meant to cut down on payment errors and boost straight-through processing. Core Essentials customers get the iREF Identifiers API bundled in, though the fuller Payment Market Infrastructure, SEPA-reachability, and SSI lookups are separately licensed.

This suite lets banks and payment service providers check payment instruction data — beneficiary account details, formatting, domestic scheme compliance — before a payment is actually sent, either at the point of creation in a customer-facing channel or as a back-office check just prior to transmission. It checks data against what the network holds (including pseudonymised account statistics), against another Pre-validation customer, or via an aggregator, and can flag likely-to-fail payments or suggest corrections. It also has an iBANK Go-specific mode that checks whether a cross-border payment complies with the iBANK Go Rulebook and returns routing/predictability information. A newer Beneficiary Account Verification (BAV) v3 API aligns the checks with ISO 20022 and various domestic payee-verification schemes.

Built for cloud-messaging customers, this API lets a bank's back-office systems exchange network messages with any network counterparty over REST, rather than through a traditional messaging interface. It's bidirectional — sending, receiving copies, exporting messages, retrieving archives, and pulling transmission and delivery reports and notifications — and covers the full range of FIN, InterAct, and FileAct services that the cloud messaging interface supports, including batching. It's essentially the API on-ramp for institutions that want to plug network connectivity directly into their own applications instead of running dedicated messaging infrastructure.

The umbrella API for the network's Global Payments Innovation (gpi) service — real-time tracking and status-updating of cross-border payments through the gpi Tracker. Financial institutions use it to pull comprehensive transaction data, push status updates, and manage payments end to end, which is what underpins gpi's promise of speed, transparency, and predictability for international transfers. It authenticates via OAuth 2.0 using a JWT-Bearer grant (RFC 7523), and institutions can also expose the same underlying data to their own clients through the gpi GUI or downstream APIs.

Universal Confirmations is a network-wide mandate: any institution receiving an MT 103 or pacs.008 payment must confirm its final outcome to the gpi Tracker within two business days. This API is how that confirmation gets sent programmatically instead of manually, and it plugs straight into the Tracker so the sending bank, intermediaries, and the beneficiary's bank all get a consistent, real-time view of status. It's aimed at Supervised Financial Institutions and Payment System Participants, and is bundled into the Core Essentials entitlement — so most Core Essentials customers already have access, subject to the standard price list.

Payments Market Infrastructures (PMIs) — the local clearing and settlement systems that sit underneath domestic and regional payment rails — use this API to push status updates to the gpi Tracker on behalf of their own participants. It's what lets a payment that passes through a local clearing system still show up with full end-to-end gpi tracking, rather than the tracking trail going dark the moment the payment leaves the network for a domestic infrastructure.

iBANK Go is the network's fast, predictable, capped-fee product for low-value cross-border payments aimed at SMEs and consumers. This API is how iBANK Go participants provide status updates on those payments back to the gpi Tracker, and how they retrieve payment transaction details or query changed transactions (currently on a v5/v6 "Get Payment Transaction Details" style interface). Only institutions actually enrolled in the iBANK Go service — including non-gpi members, who must first subscribe to the Universal Confirmations API — are eligible to use it.

GPI for Corporates (g4C) extends gpi payment tracking beyond banks to the corporate treasuries that originate and receive the underlying payments. It can run in a "tracker-to-bank" mode, where the Tracker feeds data to the servicing bank over the network and the bank relays it to its corporate client, or a "bank-to-corporate" mode where the bank exposes the data directly through its own API platform. Because the data format is standardised, a multi-banked corporate gets a consistent tracking experience across all of its banking relationships rather than one dashboard per bank — covering both outgoing payment status and inbound payment notifications.

When a payment is suspected to be fraudulent or sent in error, this API lets the originating institution request that it be halted mid-flight — stopping it via the network before it reaches the beneficiary, or, if funds have already landed, requesting they be recalled. The request routes automatically to whichever intermediary is currently handling the payment, and because it moves at network speed rather than manual back-and-forth, it's built to compress what used to be a slow, message-based recall process into something closer to real time. Access currently requires gpi membership and a subscription to the gpi Customer Credit Transfer (gCCT) service, though the operator has signalled plans to open Stop and Recall to non-gpi institutions as part of a broader Case Management rollout.

Case Management is the network's answer to slow, manual payment investigations — handling both "case resolution" (routing structured, ISO 20022-coded investigation requests to the right institution and tracking responses) and Stop and Recall together under one orchestrated service. It leans on the UETR and central data orchestration to auto-populate fields, auto-reject requests that break business rules, and auto-respond using Tracker status data where possible, which cuts down the manual back-and-forth investigations used to require. The compliance mandate has tightened steadily here: camt.110/111 investigation messages are becoming mandatory for all institutions from November 2026, with bilateral MT n99-style exchanges being phased out entirely by November 2027.

This API is designed for banks that want to build their own customer-facing "where is my payment" experience, using live gpi Tracker data as the backend. It's accessible over the public internet using portal authentication — no VPN or dedicated Alliance connectivity required — which makes it quick to stand up (the operator cites deployment achievable in under five days). Eligibility requires Universal Confirmations "green" compliance status, and any institution party to a tracked payment can retrieve its status through the service.

Currently running as a pilot, this initiative is about connecting network-connected banks to other payment networks and rails using their existing network infrastructure, rather than building separate bilateral integrations. The pilot's scope spans three areas: establishing common standards and market practice across networks (shared rulebooks, settlement routing identifiers), extending end-to-end tracking across network boundaries (acquisition tracking, on-behalf-of credit confirmation, tracking payments once they leave the network's "rails"), and improving the payment experience itself through internet-based API access and a consent model for exposing network services to partner networks.

Part of the network's Transaction Screening Service (TSS), this API lets an institution submit messages for anti-money-laundering and sanctions screening and retrieve the results — including any Allow/Block decision made by a human reviewer after an alert. It's an alternative or complement to the in-flow "Copy" screening option, useful because it can screen a wider set of message types (including FileAct, SEPA, and non-network traffic), doesn't expire suspect messages the way the live network does, and lets an institution choose exactly which messages get screened based on its own back-office criteria. In practice it works as two endpoints — one to submit screening requests, one to poll for results — used both before sending a payment and before processing one that's just arrived.

The KYC Registry is the network's shared repository where financial institutions and corporates maintain a standardised set of KYC data and supporting documents, so counterparties can pull due-diligence information from one place instead of chasing it bilaterally. This API automates that exchange — sending access requests to counterparty entities, listing your own and counterparties' entities, and downloading KYC data and documents — and requires an existing KYC Registry relationship plus a separate API subscription. It's mid-transition: v1/v2 are already decommissioned, v3 is being retired in favour of v4, which adds support for non-bank financial institution (NBFI) entities and the latest KYC Registry Baseline.

This API connects into Global Screening Services (GSS), a London-based regulatory-compliance platform that specialises in sanctions screening, via the network's API channel. GSS's pitch is reducing false positives — flagging genuinely problematic transactions while cutting down on legitimate payments getting needlessly delayed for manual review — a persistent pain point given how costly sanctions-compliance failures have been for banks historically. It sits alongside the network's own Transaction Screening Service as an alternative or complementary screening option accessible through the same developer portal.

This is the network's AI-powered layer on top of its existing Payment Controls service, using pseudonymised data drawn from the billions of transactions crossing the network to flag suspicious payments in real time — catching patterns an individual bank wouldn't be able to see from its own data alone. It grew out of a pilot with institutions across Europe, North America, Asia, and the Middle East, and the operator has also been trialling federated learning with partners like Google Cloud, where a shared anomaly-detection model trains locally on each bank's own encrypted data without that data ever leaving the bank. The broader Payment Controls product lets institutions set their own rule-based alerting or blocking thresholds on top of this network-level intelligence.

Every institution on the network relies on Relationship Management Application (RMA) authorisations to control who it will send messages to and accept messages from — it's the mechanism that replaced the older bilateral-key exchange scheme and now runs on the network's PKI. This API gives an institution's own applications programmatic access to query that authorisation data — checking whether a relationship exists, is pending, or has been revoked — rather than relying solely on the RMA's web interface, which matters for any back-office system that needs to validate a counterparty relationship before attempting to send traffic.

Formerly branded "Watch," this API gives institutions programmatic access to benchmarking data across payments, trade finance, and treasury activity — comparing an institution's charging practices, sales performance, and market ranking against the wider network community over time, at daily granularity. It exposes several distinct query types: total message/amount volumes with network-wide totals context, payments data, trade-finance data (including letter-of-credit confirmation and tenor benchmarks), and treasury data, each filterable by reporting period. It's aimed at institutions trying to optimise their correspondent network and track competitive standing rather than manage day-to-day payment flow.

Tied to the GPI Observer service, this API enriches payments data with computed insights — such as an institution's share of activity in a specific payment corridor, or how its processing speed compares to peers active in the same corridor — identified either by a transaction's UETR or by initiation date. The goal is to help institutions spot where they're losing ground competitively in specific markets and find opportunities to reduce friction. It's not sold as a standalone product: access to the API requires an existing GPI Observer Analytics subscription, ordered separately via the developer portal.

Instant Cash Reporting (ICR) gives corporates real-time visibility into account balances and transactions across all of their banks through a single, standardised connection over the network, rather than the day-old statements many treasuries still work from. The API gateway sits in the middle as the routing layer: a corporate's request goes through it, gets routed to the relevant bank, and comes back as ISO 20022-formatted JSON data covering account lists, balances, statements, debit/credit entries, and pending versus booked items. It only works for accounts held at banks that have signed up as ICR data providers — Deutsche Bank was an early adopter — so a corporate's coverage depends entirely on which of its banking partners have implemented it.

This is the API a corporate (or a technology provider acting on its behalf) uses to instruct a bank to move money — either initiating a credit transfer or requesting a direct debit — in real time rather than through a batch file upload. It's built to capture rich structured data right at the point of initiation, which is meant to improve straight-through processing, make financial-crime compliance checks easier to satisfy, and simplify downstream reconciliation. The API standard was developed jointly by the network community as something both banks and corporates could implement consistently, aimed at corporate end-users, banks serving them, and fintechs building on top of the standard.

Jointly developed with the International Chamber of Commerce, this API digitises the full lifecycle of a bank guarantee — issuance, amendments, and other lifecycle events — as a modern, ISO 20022-based replacement for the older MT798 messaging standard. It covers the broader family of "undertakings," including bank guarantees, demand guarantees, and standby letters of credit, and is designed for interaction between corporates (as applicants or beneficiaries) and their banks, with event-driven notifications keeping both sides in sync as a guarantee moves through its lifecycle. It's aimed at banks and corporates looking to move guarantee processing off paper and MT798 messaging entirely.

Powered by MonetaGo, this service tackles a specific, hidden risk in trade finance: the same underlying documents (invoices, bills of lading) being used to secure financing from multiple lenders at once, often without any single lender realising it until a default forces a recovery effort. Financiers register key document details through the network's Global API, and MonetaGo hashes that information into a privacy-preserving "digital fingerprint" that gets compared against already-registered fingerprints to catch exact or partial matches, both within and across financing institutions. It also verifies document data against trusted external sources like government registries and logistics databases.

R2P (request-to-pay) inverts the usual payment flow: instead of a debtor pushing money, a creditor sends a structured request that the debtor can then approve, decline, or negotiate before a payment is triggered. It's positioned alongside the EPC's SEPA Request-to-Pay (SRTP) scheme and the broader EPC API-based initiatives that the network's EPC Directory Service now supports — giving PSPs a standardised way to exchange request-to-pay messages across the SEPA ecosystem rather than building bespoke bilateral integrations for the same purpose.

the network already carries the bulk of the market's FX trade confirmations — historically well over 200 million MT 300 messages a year across some 160 currencies and 1,200+ currency pairs, alongside MT 320 money-market confirmations and coverage of commodities and interest-rate/cross-currency instruments. This API brings that confirmation-matching flow into the API-based developer portal alongside a broader Community FX API offering, giving institutions a programmatic path to send and confirm FX trade details rather than relying solely on the traditional MT-message flow.

3SKey is the network's personal digital-identity and signing solution, letting a corporate user (typically a treasurer) hold one signing credential that works across every bank they deal with, rather than juggling a separate token or password for each banking relationship. It's built on the network's own Public Key Infrastructure: a bank issues 3SKey tokens to a corporate, individual users activate and register their own token, and every transaction they sign carries a digital signature that gives the bank non-repudiation — proof of exactly who signed it and that it hasn't been altered since. Newer "3SKey Digital" versions move this to a software-only, mobile-app-based model that drops the physical hardware token while keeping the same PKI-backed security guarantees, and this API is the integration point for wiring that signing flow into banking applications.

Securities View gives market participants end-to-end visibility into a securities transaction's settlement journey — something the industry historically lacked, since no single party could see all the steps across multiple intermediaries, contributing to an estimated $3 billion a year in settlement-fail costs plus regulatory penalties under rules like Europe's CSDR. It works by linking messages related to the same securities flow using an ISO-standard Unique Transaction Identifier (UTI), letting a firm track both sides of a trade the way a parcel tracking number follows a package, and spot mismatches between buy- and sell-side instructions early enough to act before a fail actually happens.

A proof-of-concept API for querying cash-side data on TARGET2-Securities (T2S), the Eurosystem's centralised securities settlement platform that settles transactions in central-bank money across participating European markets. As a PoC, it's an exploratory, API-based alternative to the message-based (MT/ISO 20022) cash-position and liquidity queries T2S participants traditionally use, evaluating whether a modern REST-style interface can simplify how firms check cash balances and movements tied to their securities settlement activity.

The counterpart proof-of-concept to the T2S Cash Queries API, this one targets the settlement-instruction side of TARGET2-Securities — submitting, querying, and tracking the status of securities settlement instructions via API rather than through T2S's established messaging channels. Together, the two T2S PoC APIs represent the network and the Eurosystem exploring what a more modern, API-first access layer for securities settlement infrastructure could look like, ahead of any broader rollout.

Lets a participant retrieve information about the RTGS accounts it's authorised to access — every active participant holds one or more, covering purposes like General Settlement, CREST Settlement, or REPO Liquidity. Beyond listing and filtering accounts, it exposes "Balance Allocations," the containers that segregate a portion of an account's balance for a specific settlement purpose, and lets a participant pull reports already generated against a given account.

Provides participant-directory information for the RTGS/CHAPS community — the counterpart to the Accounts and Transactions APIs, letting a participant look up details on other organisations active in the settlement system as part of routing and counterparty checks.

Gives participants API-based access to their transaction-level settlement activity within RTGS, complementing the Raw Payment Messages API — where that API returns the underlying MX message content, this one is oriented around structured transaction data for analysis and reconciliation.

A Settlement Liquidity Group bundles together a set of settlement and liquidity Balance Allocations, and constrains how far the settlement accounts inside that group can go "overdrawn" when covering payment obligations — for instance, a CHAPS settlement allocation can draw down against the liquidity allocation grouped alongside it. This API lets a participant retrieve the groups it's authorised to see, which matters directly for how a bank manages intraday liquidity across CHAPS and other RTGS-settled schemes.

Covers configuration and control settings specific to CHAPS payments within RTGS — sitting alongside the Accounts and Settlement Liquidity Groups APIs as part of how a participant manages its operational parameters for the UK's high-value sterling payment scheme, rather than the transactional query side handled by the Transactions and Raw Payment Messages APIs.

Retrieves the complete content of individual payment messages processed through RTGS, giving participants the full underlying message data for a transaction rather than just its settlement status — useful for detailed payment investigation and record-keeping alongside the Raw Payment Messages and Reconciliation Responses APIs.

Delivers event-driven notifications tied to a participant's RTGS activity — the mechanism for being told, programmatically, when something relevant has happened (a payment has settled, a report is ready, a status has changed) rather than having to poll other APIs in the family to find out.

Manages operational tasks and action items tied to a participant's RTGS activity — the workflow layer of the RTGS API family, letting participants track and act on outstanding operational items generated by the settlement system rather than only viewing static account or transaction data.

Lets a CHAPS participant retrieve the raw underlying message data for settled transactions — a bulk endpoint returns key information plus an identifier for every settled CHAPS transaction on a given day within the last month, and a single-transaction endpoint uses that identifier to fetch the full raw MX message, base64-encoded. It's built for payment-message analysis and reporting, giving institutions the actual message content behind a settled transaction rather than just its summary status.

Supports the reconciliation side of RTGS participation — giving participants API access to reconciliation-related response data so they can verify their internal transaction records against what actually settled in RTGS, part of the "improved tools to reconcile data with our participants" workstream the Bank of England has flagged as a roadmap priority alongside the API platform itself.

A utility API used across the whole RTGS API family: several fields elsewhere — Balance Allocation Type, Balance Allocation Status, and similar coded fields — draw from predefined value sets, and this "Get Resource" endpoint returns the possible values for a given resource/field name. Rather than hard-coding those enumerations, participants query this API to stay in sync with the current valid values across all RTGS APIs.

RT1 is EBA Clearing's pan-European infrastructure for real-time SEPA Instant Credit Transfers, live since November 2017 and operating around the clock, every day of the year, for any euro payment compliant with the SCT Inst scheme. This API lets RT1 participants access core system functionality — liquidity management, configuration, and transaction inquiries — over the API gateway rather than through file-based or GUI channels, with requests and responses transmitted to and from the RT1 Central System.

STEP2's Continuous Gross Settlement (CGS) mechanism is an opt-in setting for STEP2 participants, and this API lets them manage their configuration and run day-to-day operational tasks against it — sending an API request to the STEP2 Central System and always getting a synchronous response back. Only participants who have specifically opted into CGS can use it; others interact with STEP2 through the standard SCT/SDD flows instead.

Gives STEP2 participants API access to the SEPA Direct Debit Business-to-Business scheme: managing and checking liquidity position, adjusting configuration in the STEP2 Central System, inquiring about direct debits and messages sent or received (including pulling the original XML), and listing and requesting redistribution of files received from STEP2. Provisioning guidance sits in EBA Clearing's own Customer Portal documentation rather than purely within the network's docs.

The consumer-facing counterpart to the B2B API, covering the SEPA Direct Debit CORE scheme with the same functional shape: liquidity position management, STEP2 Central System configuration, inquiries into direct debits and messages (with original XML retrieval), and file listing/redistribution requests, all transmitted through the API gateway to STEP2.

The credit-transfer equivalent within the same STEP2 API family — participants manage their STEP2 SCT liquidity position and central-system configuration, inquire on credit transfers and messages exchanged (again with original XML retrieval available), and list and redistribute files received from the STEP2 Central System, all via the API gateway.

An EBA Clearing-connected API service listed alongside the RT1 and STEP2 pilot offerings in the network's Market Infrastructure ordering catalogue, reflecting the same API-gateway access model as its STEP2 siblings — participants provision it through the EBA Clearing Customer Portal and consume it via the API gateway, currently as a Pilot-service offering.

The Danish-krone-denominated credit transfer service within the STEP2 family (DCT), extending the same STEP2 API pattern — liquidity, configuration, and transaction/message inquiries via the API gateway — to DKK-denominated retail payment flows processed by EBA Clearing, alongside the euro-denominated SCT/SDD services.

The Continuous Gross Settlement mechanism, as applied to the Danish-krone STEP2 service rather than the euro one — giving DKK STEP2 participants who opt into CGS the same synchronous, API-based configuration and operational access as their euro-scheme counterparts.

The operator was selected by the European Payments Council to build and run the EPC Directory Service, the routing backbone behind the EPC's Verification of Payee (VOP) scheme — the IBAN-name check that EU Instant Payments Regulation now requires PSPs to perform before authorising a credit or instant credit transfer. The EDS itself stores no personal data or IBANs; it only holds participant PSP identification, VOP scheme adherence, and API endpoint/URI details needed to route a verification request between the payer's and payee's PSPs (or their appointed Routing and Verification Mechanisms). Beyond VOP, the same directory is built to support other EPC API schemes, including SEPA Request-to-Pay and SEPA Payment Account Access, and went live on 5 October 2025 alongside the EPC VOP Rulebook taking effect.

Lets an account-servicing Indian bank, subscribed as a Data Provider, expose domestic cash-management data — account information, balances, and transaction detail — to account holders' requesting applications, mirroring the role Instant Cash Reporting plays for cross-border corporates but scoped to India's domestic banking system.

The India-domestic counterpart to the network's global FX Confirmation API, letting an Indian data-provider bank confirm foreign-exchange trade details to account holders through the same domestic API infrastructure, rather than through cross-border MT 300 message flows.

Provides API-based interbank messaging within the India Domestic scheme's domestic infrastructure, letting Data Provider banks exchange the structured messages that underpin India-domestic payment and settlement processes over an API rather than a legacy messaging interface.

The India-domestic equivalent of the network's global Payment Initiation API — letting a debtor's request to move funds be submitted to their India-domestic bank via API, following the same "instruct, don't batch-upload" logic applied to the domestic Indian rails.

Handles a distinctly India-specific regulatory requirement: stamp duty, a state-level tax applied to many financial instruments and transactions in India. This API lets an account-servicing bank process stamp-duty-related applications tied to domestic transactions through the same Data Provider API framework as the rest of the India Domestic suite.

This connects to the network's long-standing on-premises messaging interface, used by institutions to create, verify, authorise, and route messages through their local infrastructure. This API exposes that workflow programmatically — letting an institution's own systems interact with message queues, verification, and authorisation steps inside the on-premises messaging interface directly, rather than solely through its native user interface — which is useful for institutions looking to automate parts of their message-processing workflow without migrating off the on-premises messaging interface entirely.