When initiating payments through Banking Circle's APIs, you have several configuration options available to customize how your payments are processed and routed.

This article covers the key options you can specify when initiating payments:

Charge bearer configuration
Purpose codes for specific countries/currencies

Charge Bearer

A charge bearer code determines how transaction charges are distributed between the sender and beneficiary. By default, payments are sent with charge bearer SHA.

You can specify other charge bearer values, such as OUR or BEN. Whilst we support these values, we cannot always guarantee that they will applied as instructed, as they may be overridden by the payment rail used to execute the payment.

Note: This feature must be enabled for you to use charge bearer values other than SHA. Contact us to request activation.

Available Charge Bearer Options

The charge bearer options available depend on the payment initiation method used:

Standard API Endpoints

For single, bulk and agency/correspondent banking payment initiation endpoints:

Charge bearer code	Description
`OUR`	All transaction charges are to be borne by the ordering customer. A list of currencies which guarantee the `OUR` option can be shared.
`SHA`	All transaction charges other than the charges of the financial institution servicing the ordering customer account are borne by the beneficiary customer.
`BEN`	All transaction charges are to be borne by the beneficiary.

ISO20022 Endpoints (pain.001)

When using the pain.001 endpoint:

Charge bearer code	Description
`CRED`	All transaction charges are to be borne by the creditor.
`DEBT`	All transaction charges are to be borne by the debtor.
`SHAR`	For credit transfers: Transaction charges on the sender side are borne by the debtor, transaction charges on the receiver side are borne by the creditor. For direct debits: Transaction charges on the sender side are borne by the creditor, transaction charges on the receiver side are borne by the debtor.
`SLEV`	Charges are applied following the rules agreed in the service level and/or scheme. Typically equivalent to `SHA`/`SHAR`.

Charge Bearer Processing

We process charge bearer instructions based on two key factors:

Your charge bearer configuration
The payment rail selected for execution

The system will either:

Carry forward your instructed charge bearer value, or
Overwrite it based on scheme requirements

For example, the SEPA Credit Transfer scheme only allows the SHA charge bearer. If you instruct a payment with charge bearer OUR, but our routing logic determines the payment should be executed via SEPA Credit Transfer, the charge bearer value will automatically be overwritten to SHA.

We will not reject a payment if the charge bearer is not supported by the payment rail used to execute the payment.

Tracking Charge Bearer Changes

You can monitor both the instructed and actual charge bearer values through:

The GET /api/v1/payments/singles endpoint
Reconciliation reports
The outgoing payment processed webhooks (see Webhooks payload examples)

These values are exposed through two properties:

instructedChargeBearer: Your original instruction
chargeBearer: The final value used for execution

While a payment remains in 'Pending processing' status, the chargeBearer value matches the instructedChargeBearer.

Purpose Codes

Some countries and currencies require a purpose of payment code within the payment instruction. This requirement enables beneficiary banks and government authorities to effectively monitor and categorize incoming payments.

CNH to China

For CNH payments to China, a purpose code is mandatory. Payments without a valid purpose code may be rejected, delayed or subject to additional charges.

The purpose code is supported via Client Portal and API. While there is no direct support for instruction via SWIFT, the value is automatically converted to Field 72 in the outgoing MT103 messages.

Supported purpose codes:

Purpose code	Description
`GOD`	Cross-border goods trade
`STR`	Cross-border service trade
`CTF`	Cross-border capital item/transfer
`OTF`	Other transfer

SAR to Saudi Arabia

The Saudi Arabian Monetary Agency (SAMA) requires a purpose of payment for funds transfers to Saudi Arabia. This is a free-format text field with the following requirements:

Format: SWIFT standard (140 characters, 4 lines, 35 characters each)
Language: English only
Restricted characters: Cannot use !@#$%^&_()?/>\<":|}\{+=_-.

For clients instructing via Client Portal or API, please populate this information within the 'Remittance Information' field within line 1.

For clients instructing via SWIFT, populate the purpose code in Remittance Field (field 70) on line 1.

Note: Transactions submitted without a purpose of payment in Payment Details (SWIFT Field 70) may be held and ultimately rejected.

All currencies to United Arab Emirates

Payments to UAE accounts from abroad must satisfy two requirements:

Include a payment purpose code
Use IBAN format for beneficiary account

The purpose code should be included in the remittance information field (Field 70) with the following format:
/BENEFRES/AE//POP/<3-character-code>/
or
/ORDERRES/AE//POP/<3-character-code>/

Note: Transactions submitted without a purpose of payment in Payment Details may be held and ultimately rejected by Banking Circle's correspondent bank or the ultimate beneficiary bank.

For the complete list of valid UAE purpose codes, refer to the Central Bank of UAE documentation.