972-836-7750 Request a demo Talk to an expert
Talk to an expert Request a demo Call sales 972-836-7750

EDIFACT message guide · Statistics and reporting

BOPCUS Balance of payment customer transaction report

The UN/EDIFACT message banks use to report individual customer transactions processed in a period to the balance of payments compiler.

Sent by
Bank
Received by
Balance of payments compiler, such as a central bank
Standard
UN/EDIFACT · Batch message
X12 equivalent
No direct equivalent

What is the EDIFACT BOPCUS message?

BOPCUS is the UN/EDIFACT balance of payment customer transaction report. The directory defines it as a message sent by banks to the balance of payments (BOP) compiler to report individual customer transactions, debits and credits, processed during a specific period.

Where reporting schemes collect transaction-level data, banks report each cross-border payment of their customers with its purpose code, counterparty country and amount. The purpose information often comes from the customer itself, for example through BOPINF. Thresholds and code lists are set by each national compiler.

How the EDIFACT BOPCUS message worksDiagram of the UN/EDIFACT BOPCUS Balance of payment customer transaction report message. Bank sends it to balance of payments compiler, such as a central bank. It usually follows BOPINF. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and DTM (Date/time/period) and body and segment groups: the required SG2 loop with NAD (Name and address) and the required SG3 loop with LIN (Line item). 5 conditional segment groups are listed by their trigger segment.How the EDIFACT BOPCUS message worksBalance of payment customer transaction report: who sends it, where it fits and what the directory marksmandatory1 WHERE IT FITSUSUALLY FOLLOWSBOPINFBalance of paymentinformation fromcustomerBOPCUSSENDERBankRECEIVERBalance of paymentscompiler, such as acentral bankCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage BOPCUSUNH … UNTSTART OF MESSAGEBGMBeginning of messageDTMDate/time/periodBODY AND SEGMENT GROUPSMandatory group SG2 · repeats up to 9NADName and addressMandatory group SG3 · repeats many timesLINLine item+ 5 conditional groups, starting with:RFFNADMOARCSBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for BOPCUS. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT BOPCUS message worksDiagram of the UN/EDIFACT BOPCUS Balance of payment customer transaction report message. Bank sends it to balance of payments compiler, such as a central bank. It usually follows BOPINF. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and DTM (Date/time/period) and body and segment groups: the required SG2 loop with NAD (Name and address) and the required SG3 loop with LIN (Line item). 5 conditional segment groups are listed by their trigger segment.How the EDIFACT BOPCUSmessage worksBalance of payment customer transactionreport: who sends it, where it fits and what thedirectory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSBOPINFBalance of payment informationfrom customerBOPCUSSENDERBankRECEIVERBalance ofpaymentscompiler, suchas a centralbankCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message BOPCUS (UNH … UNT)START OF MESSAGEBGMBeginning of messageDTMDate/time/periodBODY AND SEGMENT GROUPSMandatory group SG2 · repeats upto 9NADName and addressMandatory group SG3 · repeatsmany timesLINLine item+ 5 conditional groups, starting with:RFFNADMOARCSBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for BOPCUS.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends BOPCUS, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around BOPCUS and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide, such as an industry subset or a partner’s own guide, usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Reporting customers' individual cross-border payments
  • Supplying transaction-level data for national statistics
  • Reporting purpose codes and counterparty countries

Where it fits in the message flow

Usually follows BOPINF Balance of payment information from customer
This message BOPCUS Balance of payment customer transaction report

Structure

Mandatory segments in BOPCUS (directory D.21A)

In UN/EDIFACT directory D.21A, the BOPCUS message has 29 segment positions arranged in 8 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement, not your trading partner’s: each partner’s message implementation guide names the directory it uses, often an older one such as D.96A or D.01B where the structure can differ, makes some conditional segments mandatory and restricts the codes.

  • UNH
  • BGM
  • DTM
  • SG2 (NAD)
  • SG3 (LIN)
  • UNT

Practical example

BOPCUS in practice

A bank processes thousands of cross-border payments for its corporate customers each month. At month end it sends the central bank a BOPCUS listing each payment with the customer, amount, currency, counterparty country and the purpose code supplied by the customer. The central bank aggregates the data into the balance of payments.

Implementation

Implementation considerations for BOPCUS

  • Collect purpose codes from customers at payment time.
  • Follow the compiler's code lists and thresholds.
  • Reconcile reported transactions with payment records.
  • Protect customer data in line with banking secrecy rules.

How ECOM helps

Automate BOPCUS with ECOM

Industry

Financial Services

Secure file transfer and B2B integration for banks and financial institutions.

Solution

Financial Document Automation

Automate invoices, remittances, payment files and bank statements from capture to posting.

Solution

EDI Integration

Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.

Compare X12 and EDIFACT, or see answers to general questions in the EDI FAQ.

Related messages

Related statistics and reporting messages

All 8 statistics and reporting messages

Need help with BOPCUS?

ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.

Request a Demo Contact us