International Wire¶

International wires move funds between a U.S. bank and a foreign bank. GIB submits international wires through our U.S. correspondent and onward through the SWIFT network to the destination bank. Settlement timing varies by destination; for specifics, see the central Timing & cutoffs.

All international wires are submitted in ISO 20022 (pacs.008.001.08) format. This is the SWIFT cross-border standard following the CBPR+ migration; legacy MT103 submission is no longer supported. See also our Guide.

The same ISO 20022 (wire20022) standard is used for domestic wires; see Domestic Wire.

International wires carry significantly more required structured data than domestic wires: beneficiary address subcomponents, intermediary banks where applicable, country-specific purpose codes, and tax-reference codes for certain destinations.

When to use it¶

• Cross-border B2B or B2C payments
• Currency conversion via correspondent banks
• High-value international transfers that can't tolerate ACH/IAT settlement timing

For consumer-scale, lower-value international flows, consider International ACH (IAT), slower but materially cheaper.

Bundling many end-user payments¶

Fintechs handling cross-border consumer remittance typically don't send one international wire per end user. The common pattern is to bundle many end-user payments into a single outbound wire to a liquidity provider, international affiliate, or payment service provider, who then pays out the underlying beneficiaries in the destination country and currency.

In that pattern the customer payments are nested, and the wire itself is the only event GIB sees on the rail. Create a Subtransaction for each underlying customer payment in the wire, so the per-end-user record reaches GIB's recordkeeping, monitoring, and OFAC screening. The Subtransaction carries the true sender and ultimate beneficiary; the wire carries the funds. Without that link, the bulk wire is a nested correspondent flow that's hard to defend on BSA/AML and OFAC.

See Subtransactions for the concept, the link semantics, and how to attach Subtransactions to an outbound wire.

Operations¶

To trace a wire through the SWIFT network, contact info@gibank.com with the UETR; there is no public trace endpoint.

Receiving wires from end users¶

Your end users may need to wire funds into your accounts at GIB from a foreign bank. For the standard receive instructions to share with their sending bank, see Wire routing instructions → International wires.

Transfer purposes and details¶

GIB requires the use of a purpose code for international wires. Most countries have adopted the standard list of purpose codes Standard Purpose Codes, others have adopted either a subset of the list or have their own list of purpose codes that must be used (e.g., China, UAE, India) (see below).

You can specify the purpose code in the <Purp> element (when submitting ISO 20022 XML directly).

• Use <Cd> for standard 4-character ISO codes.
• Use <Prtry> for country-specific proprietary codes.

Remittance information¶

Some countries require that a payment purpose be specified. For per-country remittance information requirements, see the Country-specific guides.

Mandatory purpose codes¶

Generally, you can use one of the Standard Purpose Codes listed below. Some countries additionally require mandatory, proprietary codes.

Note: While the API accepts transfers without such information, omission may result in delays, rejections, or returns by the beneficiary bank. In such cases, the risk of non-acceptance rests with the sender.

For per-country mandatory purpose codes and code sources, see the Country-specific guides.

Highly recommended purpose codes¶

Generally, you can use one of the Standard Purpose Codes listed below. Some countries additionally have recommended, proprietary codes.

Note: While the API accepts transfers without such information, omission may result in delays, rejections, or returns by the beneficiary bank. In such cases, the risk of non-acceptance rests with the sender.

For per-country recommended purpose codes, see the Country-specific guides.

Standard purpose codes¶

Note: While the API accepts transfers without such information, omission may result in delays, rejections, or returns by the beneficiary bank. In such cases, the risk of non-acceptance rests with the sender.

The ISO 20022 standard purpose codes are listed in the Purpose Code Reference.

Account numbers and addresses¶

Some countries require specific IBAN and address formats. The country Base-API endpoint returns the current requirements per destination; check it before submitting to a destination you haven't sent to before.

Valid characters (SWIFT)¶

Valid characters for international wires are defined by SWIFT. Messages with invalid characters are rejected by the SWIFT system. Use this regular expression to detect invalid characters:

[^A-Za-z\d/\-?:( ).,'\+]

Valid characters include:

• Alphanumeric: A-Z, a-z, 0-9 and spaces
• . (period)
• , (comma)
• ? (question mark)
• : (colon)
• / (forward slash)
• ( (left parenthesis)
• ) (right parenthesis)
• ' (apostrophe)
• + (plus)
• - (minus/hyphen)

The set above is the SWIFT baseline (the "FIN-X" character set) used for most message elements.

Extended characters (names, addresses and remittance)¶

Under CBPR+, the name and address fields of all parties, the remittance information (structured and unstructured), and email elements support an extended set: the FIN-X characters above plus the following.

! # $ & % * = ^ _ ` { | } ~ " ; < > @ [ \ ]

Temporary limitation: GIB's international correspondent does not yet accept eight of these extension characters in party name and address elements: * ^ ` { } [ ] |. Until it does, they are rejected there (they remain valid in remittance information). This restriction will be lifted once the correspondent confirms support.

Every other text element — party identifications (Id/OrgId/Othr, Id/PrvtId/Othr: Id, Issr, SchmeNm/Prtry), payment identifications (PmtId/InstrId, EndToEndId, TxId) and structured remittance references (Strd/CdtrRefInf/Ref, Strd/RfrdDocInf/Nb) — stays limited to the FIN-X baseline above.

Wires whose elements contain characters outside the applicable set are rejected with an HTTP 400 BusinessError identifying the offending field(s) — both file parsing and outbound generation fail — since such characters are rejected by the network downstream.

For the Fedwire character set used on domestic wires, see Domestic Wire → Valid characters (Fedwire).

ISO 20022 essentials¶

For XML structure, address formatting, dynamic identifiers, fixed values, sender details, and a full sample file, see the ISO 20022 Wire Reference.

Receiver routing for international wires¶

Fedwire cannot route directly to a SWIFT BIC, so international wires must route through GIB's U.S. correspondent (UBB), which acts as the gateway to the SWIFT network.

• InstdAgt (Instructed Agent) must be UBB (see Sender details in the reference guide for the block).
• CdtrAgt (Creditor Agent) is the final foreign bank, identified by SWIFT BIC (BICFI).

Required InstdAgt block for international wires:

<InstdAgt>
  <FinInstnId>
    <ClrSysMmbId>
      <ClrSysId>
        <Cd>USABA</Cd>
      </ClrSysId>
      <MmbId>091001322</MmbId>
    </ClrSysMmbId>
  </FinInstnId>
</InstdAgt>

Nm and PstlAdr are not allowed inside InstdAgt.

Beneficiary account (CdtrAcct)¶

For international wires, use IBAN (where applicable for the destination country) or otherwise the account number under Othr/Id. The Country-specific guides endpoint indicates IBAN requirements per destination.

Lifecycle¶

International wires follow the standard transaction state machine, see Transactions. Additional considerations:

• processing may persist longer than domestic wires (intermediary handoff to SWIFT)
• posted indicates GIB's outbound is confirmed, but not necessarily that the destination bank has credited the beneficiary; the SWIFT path can take additional time
• Wire returns from the destination side arrive as separate inbound transactions

Timing & cutoffs¶

For international wire submission cutoffs and processing windows, see the Timing & cutoffs.

Failure modes¶

See Errors for the response shape.

Idempotency¶

Always populate the external_key field in the request body. International wires that succeed on retry without an external_key are even harder to reverse than domestic wires due to the multi-hop SWIFT path. See Idempotency.

Tracing¶

The UETR (Unique End-to-End Transaction Reference) survives every SWIFT routing hop. If a wire is delayed or appears stuck, send the UETR to info@gibank.com; we can trace the wire's path through the network.

Related concepts¶

• Domestic Wire, when both parties are in the U.S.
• Wire routing instructions, receive instructions for inbound wires
• ACH, see SEC code IAT for ACH-rail international payments
• Transactions
• Errors
• Webhooks, outbound_wire20022_transaction_* / inbound_wire20022_transaction_*
• Idempotency