--- title: "GBP Cross-Border" metaTitle: "GBP Cross-Border" order: 7 showPageMenu: true --- import EndpointBlock from "src/components/endpoint-block" import WebhookPlaceholder from 'src/components/webhook-placeholder' import Callout from "src/components/callout"; import ExternalLink from 'src/components/external-link'; ## GBP Cross-Border

Deprecation notice

The following endpoints were deprecated on 13 May 2026:
- POST /payments/cross-border-sterling/v3/payments

This endpoint will continue to be supported until further notice. An updated removal date will be communicated once we have clarity from SWIFT and the Bank of England on their 2027 scope, enabling us to confirm when this endpoint can no longer be supported. Version 4 of this endpoint is now available. Please reach out to your Client Director with any questions.

You can refer to our versioning policy and support lifecycle information.

Cross-border payments are financial transactions where the payer and the recipient are based in separate countries. Our GBP Cross-Border payment product enables you to send sterling payments to any sterling account, in any permissible overseas jurisdiction. Payments are guaranteed to settle on the same-day, as long as the instruction is received before 5pm UK time on that working day. There is no limit to the amount that can be sent using this service. You can send GBP cross-border payments using the [POST /payments/cross-border-sterling/v4/payments](#send-a-gbp-cross-border-payment) endpoint. Settlement details are provided to you via the [Transaction Settled](#transaction-settled-webhook) webhook. It is important to verify your firewall settings to ensure that they do not block Transaction Settled webhook notifications, which can include a large payload due to the size of the Iso20022XmlDocument field. **Things to note:** - You can initiate a payment during the sterling availability period, 08:00 to 17:00 (UK time), on business days. Payments sent before or after this window will be rejected with a 400 Bad Request response. - If you use **version 3** of the endpoint and choose to provide the optional Intermediary Agent field, the provided BIC must be a GB BIC belonging to a CHAPS direct participant. Additionally, there must be a valid payment routing path from the Intermediary Agent to the Creditor Agent. If there is no valid routing path, or you provide a BIC that is not a GB BIC and a CHAPS Direct Participant, the payment will be rejected. If you're unsure, it's best to leave the Intermediary Agent field blank. - You can recognise a Transaction Settled webhook that describes a GBP Cross-Border payment by checking the **TransactionSource** is set to **Cross Border GBP**. - Review the [address guidance](#guidance-on-populating-address-information) before submitting outbound payments. If you receive a Transaction Rejected webhook outside of industry opening hours, retry the payment during the next open window. The GBP Cross-Border endpoint supports the new ISO 20022 payment message formats, specifically pacs.008. ### What's changed in version 4 Version 4 of the GBP Cross-Border endpoint introduces the changes required to remove unstructured address types, together with a small number of ClearBank enhancements. If you are migrating from version 3, the key differences are: - On the `Other` account identification block for `sourceAccount`, `debtorAccount` and `creditorAccount`: `schemeName` is now enforced and the legacy `proprietary` field has been removed. - The amount field has been renamed from `instructedAmount` to `interBankSettlementAmount` to more accurately align with ISO 20022 wording. - For the Creditor Account, GBP Cross-Border v4 offers `BBAN` and `Other` options in `schemeName`, whereas domestic CHAPS v6 offers `BBAN` and `SortcodeAccountNumber` options. (In both cases, these are alternatives to choosing the `IBAN` value.) The `Other` option in GBP Cross-Border allows you to accommodate non-UK identification formats required for cross-border payments. ### Guidance on populating address information When sending outbound GBP Cross-Border payments, we strongly recommend that you provide as much address information as possible for both: - the **remitter** (`Debtor`) - the **beneficiary** (`Creditor`) Different overseas jurisdictions have different requirements for address detail. Providing full address details reduces payment delays and post-submission requests for information. In [POST /payments/cross-border-sterling/v4/payments](#send-a-gbp-cross-border-payment), the following `postalAddress` fields are mandatory and must always be provided: - `townName` - `country` - `postCode` The following fields are optional, but strongly recommended where available: - `buildingNumber` - `buildingName` - `streetName` ### Version 4 mandatory fields In line with the Bank of England's ISO 20022 data enhancement requirements, you will be required to provide additional details on the debtor and creditor such as the Legal Entity Identifier (LEI), Purpose Code and Category Purpose Code. You can find further details about these fields on our Knowledge Centre, or access a list of all the recommended Purpose and Category Purpose Codes and their definitions on the Bank of England website: UK recommended Purpose Code PDF. #### Legal Entity Identifier (LEI) The LEI is a 20-character, alpha-numeric code based on the ISO 17442 standard and contains information about an entity’s ownership structure. Providing the LEI is mandatory for pacs.008 where the party being described (debtor or creditor) is a financial institution. Otherwise, it is an optional field but strongly recommended to include when the party is an organisation. #### Purpose Codes and Category Purpose Codes The Purpose Code captures the nature of the payment and should be transported end to end. The Purpose Code is 4 characters used to abbreviate the purpose, for example, IVPT - Invoice Payment. The Category Purpose Code is used to identify the broader nature of the payment and is used by agents. There are fewer Category Purpose Codes as this is providing a higher level understanding. In total there are 127 Purpose Codes and 28 Category Purpose Codes. To help make sense of the various codes, they have been broken down into eight categories in the following table. The categories have been created by ClearBank to support our clients in finding the appropriate codes for their use case when making GBP Cross-Border payments. ClearBank are mandated to prioritise identifying which payments are linked to Property – therefore if you are looking to complete a property-related payment, ensure that you make use of these Purpose Codes in your payment instruction. For your convenience, Purpose Codes and Category Purpose Codes with the same value are shown in bold. |Group|Name|Description|Purpose Codes|Category Purpose Codes| |---|----|---|---|---| | 1 | Personal finance | These codes can be used if the payment relates to something specific to a person, for example, alimony payment or dental services. | ALMY, BECH, BENE, CHAR, CLPR, DNTS, EDUC, GAMB, LOTT, LTCF, MDCS, **SALA**, SAVG, **SSBE**, SUBS, TRFD, VIEW | GP2P, MP2P, **SALA**, **SSBE**| | 2 | Finance and accounting | These codes can be used if the payment relates to invoices or managing finances. | ACCT, AREN, BKIP, BKPP, **CASH**, CSDB, **INTC**, INTP, IVPT, LIMA, NETT, REOD, **TREA**, **LOAN**, LOAR, **INTE** | **CASH**, **TREA**, **INTC**, **INTE**, **LOAN** | | 3 | Corporate | These codes can be used if the payment relates to topics that impact corporations. | ADCS, AGRT, BEXP, **BONU**, COMC, COMM, COMP, COMT, CPYR, DEPT, DIVD, ECPR, EPAY, GDSV, GIFT, GSCB, HREC, INSM, PEFC, REBT, REFU, RELG, ROYA, TRAD, **SUPP**, **PENS** | **BONU**, DIVI, DVPM, **PENS**, RRCT, **SUPP** | | 4 | Tax & government specific | These codes can be used if the payment relates to tax or for government related activities. | ESTX, FAND, **GOVT**, HSTX, PENO, RDTX, TAXR, **TAXS**, **VATX**, **WHLD**, PTXP | **GOVT**, **TAXS**, **VATX**, **WHLD** | | 5 | Insurance | These codes can be used if the payment relates to insurance. | HLTI, INPC, INPR, INSC, INSU, INTX, LBRI, LIFI, PPTI | OTHR | | 6 | Property | These codes must be used if the payment is related to property. **It is a priority to identify these payments correctly**. | HLRP, HLST, PCOM, PDEP, PLDS, PLRF | OTHR | | 7 | Financial products | These codes can be used if the payment relates to a financial product. | BKFE, BNET, BOCE, **CBLK**, CMDT, COLL, **CORT**, DERI, EXTD, FNET, FORW, FREX, FUTR, FXNT, **HEDG**, INVS, OTCD, REPO, SBSC, **SECU**, SLEB, SWFP, SWPP, SWRS, SWUF, LREB, LREV | **CBLK**, **CORT**, **HEDG**, TRAD, **SECU** | | 8 | Bills and fees | These codes can be used if the payment being made is related to a bill or fee being applied. | CBTV, CDBL, LICF, SERV, TCSC, UBIL, WTER, PHON, ELEC, GASB, CPKC, FEES, BLDM, DBTC, RENT | CCRD, DCRD, FCOL | #### Common use case examples The following table details common uses of Purpose Codes and Category Purpose Codes which you can refer to when making payments. |Use case|Purpose Code|Category Purpose Code| |---|----|---| | Buying a property – payment of a deposit | PDEP – Property Deposit | OTHR – Other Payment | | Buying a property – final payment to complete the purchase of a property | PCOM – Property Completion Payment | OTHR – Other Payment | | Payments made in relation to salaries | SALA – Salary Payment | SALA – Salary Payment | | Moving money for the same company from a ClearBank to a non-ClearBank account | INTC – Intra Company Payment | INTC – Intra Company Payment | | Moving money for the same individual(s) from a ClearBank to a non-ClearBank account | INTP – Intra Party Payment | GP2P – Person to Person Payment | | Paying a supplier | SUPP – Supplier Payment | SUPP – Supplier Payment | | Paying a business expense | BEXP – Business Expenses | OTHR – Other Payment | | Paying a generic tax bill | TAXS – Tax Payment | TAXS – Tax Payment | | Payment of an insurance premium | INSU – Insurance Premium | OTHR – Other Payment | | Paying VAT | VATX – Value Added Tax Payment | VATX – Value Added Tax Payment | | Making a payment for a trade | TRAD - Trade | CORT – Trade Settlement Payment | | Paying an invoice | IVPT – Invoice Payment | CASH – Cash Management Transfer | | Paying fees of some sort | FEES – Payment of Fees | OTHR – Other Payment | | Payment of building maintenance | BLDM – Building Maintenance | OTHR – Other Payment | | Repayment of a loan | LOAR – Loan Repayment | LOAN - Loan | | Funding your account at Bank of England (pacs.009) | LIMA – Liquidity Management | CASH – Cash Management Transfer | ### Populating the Creditor field in pacs.008 messages The `Creditor` field in [POST /payments/cross-border-sterling/v4/payments](#send-a-gbp-cross-border-payment) (pacs.008 messages) identifies the party who will receive the funds. This party can be an **individual**, a **business**, or a **financial institution**. Correctly filling in this field ensures the payment reaches the intended recipient and complies with ISO 20022 formatting rules. If the field is populated incorrectly, the payment may be delayed or rejected. #### Understanding Creditor and Creditor Agent roles In a payment transaction, there are two key parties: 1. **Creditor**: The person or organisation receiving the funds. This could be an individual, a business, or a financial institution (FI). 2. **Creditor Agent**: The financial institution that holds the account into which the funds are credited. This is always a financial institution and must be identified using a valid 11-character or 8-character **Business Identifier Code (BIC)**. To ensure correct population of fields in pacs.008 payment messages, follow these guidelines based on the type of Creditor: ##### If the Creditor is an individual: - Use the `privateIdentifier` object for the Creditor identification block. - Do **not** populate the `Creditor > OrganisationIdentifier` object. - **Populate** the `CreditorAgent > BIC` field with the BIC of the FI that holds the Creditor’s account. ##### If the Creditor is a business: - Use the `organisationIdentifier` object for the Creditor identification block. - Do **not** populate the `Creditor > PrivateIdentifier` object. - **Populate** the `CreditorAgent > BIC` field with the BIC of the FI that holds the Creditor’s account. ##### If the Creditor is a financial institution: - Use the `organisationIdentifier` object for the Creditor identification block. - Do **not** populate the `Creditor > PrivateIdentifier` object. - Optionally **populate** the `Creditor > OrganisationIdentifier > BIC` field with details of the FI's BIC. - **Populate** the `CreditorAgent > BIC` field with the BIC of the FI that holds the Creditor’s account. #### Valid payload examples **Sending a payment to a private individual** ``` { "instructionIdentification": "INST202509190001", "endToEndIdentification": "202509190123456", "instructedAmount": { "amount": 1416.98, "currency": "GBP" }, "sourceAccount": { "iban": "GB00FAKE00000000000000" }, "debtorAccount": { "iban": "GB00FAKE11111111111111" }, "debtor": { "name": "Jane Smith", "postalAddress": { "buildingNumber": "40", "streetName": "Dennenlaan", "townName": "Het Ambacht", "country": "NL", "postCode": "3901" } }, "creditorAccount": { "iban": "DE89370470440532013000" }, "creditor": { "name": "Johnny James", "postalAddress": { "buildingNumber": "38", "streetName": "Gotthardstrasse", "townName": "Freistaat Sachsen", "country": "DE", "postCode": "09052" }, "privateIdentifier": { "otherIdentification": "568237456" } }, "creditorAgent": { "bic": "CITIDEFFXXX" }, "purpose": "SALA", "categoryPurpose": "SALA", "remittanceInformation": { "creditorReferenceInformation": "SALARY25112024" } } ``` **Sending a payment to a business** ``` { "instructionIdentification": "INST202509190002", "endToEndIdentification": "202509190654321", "instructedAmount": { "amount": 2500.00, "currency": "GBP" }, "sourceAccount": { "iban": "GB00FAKE00000000000001" }, "debtorAccount": { "iban": "GB00FAKE11111111111112" }, "debtor": { "name": "Jane Smith", "postalAddress": { "buildingNumber": "40", "streetName": "Dennenlaan", "townName": "Het Ambacht", "country": "NL", "postCode": "3901" } }, "creditorAccount": { "iban": "DE89370470440532013000" }, "creditor": { "name": "Business Limited", "postalAddress": { "buildingNumber": "38", "streetName": "Gotthardstrasse", "townName": "Freistaat Sachsen", "country": "DE", "postCode": "09052" }, "organisationIdentifier": { "lei": "844517J3KKERBCP9QQ94", "otherIdentification": "2132334343434" } }, "creditorAgent": { "bic": "CITIDEFFXXX" }, "purpose": "SALA", "categoryPurpose": "SALA", "remittanceInformation": { "creditorReferenceInformation": "INVOICE20250919" } } ``` **Sending a payment to a financial institution** ``` { "instructionIdentification": "INST202509190003", "endToEndIdentification": "202509190987654", "instructedAmount": { "amount": 50000.00, "currency": "GBP" }, "sourceAccount": { "iban": "GB00FAKE00000000000002" }, "debtorAccount": { "iban": "GB00FAKE11111111111113" }, "debtor": { "name": "Jane Smith", "postalAddress": { "buildingNumber": "40", "streetName": "Dennenlaan", "townName": "Het Ambacht", "country": "NL", "postCode": "3901" } }, "creditorAccount": { "iban": "DE89370470440532013000" }, "creditor": { "name": "Bank PLC", "postalAddress": { "buildingNumber": "38", "streetName": "Gotthardstrasse", "townName": "Freistaat Sachsen", "country": "DE", "postCode": "09052" }, "organisationIdentifier": { "bic": "CITIDEFFXXX", "lei": "844517J3KKERBCP9QQ94", "otherIdentification": "2132334343434" } }, "creditorAgent": { "bic": "CITIDEFFXXX" }, "purpose": "TREA", "categoryPurpose": "TREA", "remittanceInformation": { "creditorReferenceInformation": "TREASURY20250919" } } ```