IDA = Interchange of Data between Administrations

EEG6 Statistics - the standardisation body for EDI in statistics

If you want to know more about us, please contact:

Address: Chair/Secretariat EEG6/WG6

c/o Peter Hofman

De Nederlandsche Bank

P.O. Box 98

1000 AB Amsterdam

Phone: +31-20-5243313

Fax: +31-20-5242512

or

Address: Eurostat

c/o Mr. J.-C. Roman

unit Balance of Payments

Jean Monnet Building

L-2920 Luxemburg

Phone: +352-4301-33548

Fax: +352-4301-33859

 

 

Preface

Eurostat

1.1 Introduction

1.1.1 Purpose

1.1.2 EDIFACT

1.1.3 Summary

1.2 Balance of payments and International investment position

1.2.1 Concept

1.2.2 Purpose

1.2.3 BOP information

1.2.4 IIP information

1.3 BOP and IIP data reporting and EDIFACT messages

1.4 Reporting BOP and IIP data and the parties involved

1.4.1 General collection system

1.4.2 Survey-based system

1.5 Data flow analysis

1.5.1 PAYORD/PAYMUL/PAYEXT

1.5.2 BOPINF (Inf = information)

1.5.3 BOPCUS (Cus = customer)

1.5.4 BOPDIR (Dir = direct)

1.5.5 BOPBNK (Bnk = bank)

1.5.6 GESMES/CB (subset of the GESMES message)

1.5.7 FINPAY (Financial payment)

1.6 Long-run perspective and legal aspects

1.7 EDIFACT messages: a flexible approach

1.8 EDIFACT message presentation: branching diagram

1.9 Cancellation or modification of a previous message

1.9.1 FINCAN

1.9.2 APERAK

1.10 Direct debiting (DIRDEB)

1.11 Security of the EDI-BOP messages

1.11.1 General

1.11.2 Exposure to risks

1.11.3 Various levels of security with regard to the confidentiality of information

1.11.4 Message content integrity, authentication and non-repudiation

annex 7 : POSSIBLE USES OF EDIFACT MESSAGES 123

Under the aegis of EUROSTAT, the statistical organisation of the EC, the EDI BOP task force started research in July 1998 into the possibilities of using EDIFACT messages for collecting balance-of-payments (BOP) and international investment position (IIP) data.

The purpose of this document is to outline the possibilities of using EDIFACT messages for reporting Balance-of-Payments (BOP) and International Investment Position (IIP) data. For the sake of simplicity, references to BOP data should generally be considered to include IIP data; in some cases the IIP data are explicitly mentioned. The use of these messages is to the advantage of all parties involved. It is a paperless process of reporting information to statistical authorities. Automated reporting is quicker and results generally in higher-quality data. Moreover, reporting companies and intermediating banks can save costs by less human intervention and less coding work.

The use of the EDIFACT standard could be an additional stimulant to be able to reach paperless reporting.

EDIFACT is an EDI standard. EDI (Electronic Data Interchange) is defined to be the transfer of structured data by agreed message standards from computer to computer by electronic means (C. Nelson; EDI, The key to business success, 1990). Among the different message standards, EDIFACT (Electronic Data Interchange for Administration, Commerce and Trade) has attained a position of superiority, especially since it was adopted by the United Nations (UN) and later by the International Standards Organisation (ISO standard 9735). EDIFACT has also been accepted as a Euronorm (EN29735). Recently, decisions have been made for the future conversion of the other message standards into EDIFACT format. In early 1995 the CFMB (Committee on Monetary, Financial and Balance of Payments statistics) agreed on the adoption of the use of EDIFACT in reporting Balance of Payments information to international institutions as soon as possible.

Worldwide, EDIFACT message development work has been divided into six EDIFACT boards which coordinate the work done by different message development groups. In Europe the work has been coordinated by the Western European EDIFACT Board (WEEB) and, from late 1995, by the European Board for EDI Standardization (EBES). The statistical EDIFACT messages are developed in the EDI Expert Group 6 Statistics (EBES/EEG6); the development of the Balance of Payments messages belongs to Working Group 6 (EEG6/WG6). This group also works under the EU Commission as the CMFB/BOP Working Party/Task force 3 ('EDI BOP' group).

The BOP messages to be used fall into two categories. Reporting BOP information could be done by using existing EDIFACT messages. On the other hand, it was necessary to develop new messages. The intention is that the messages cover all data-collecting systems and provide all information needed. The approach followed in developing the new messages has been flexible in the sense that the use of most segments of the messages will be optional; however, national guidelines/regulations could make the use of (part of) these segments mandatory.

Chapter 1 is of a general nature, explaining some aspects of compiling the balance of payments, on the one hand, and dealing with EDIFACT, on the other. Chapter 2 goes into the messages in more detail. For each message one or more narratives are given to explain the function of the message. The corresponding translation into EDIFACT terms is also given. Chapter 3 gives an overview of possible uses by various countries of EDI BOP messages in the compilation of BOP and IIP. In the Annexes full details of all messages are given.

A summary of the possibilities as the EDI BOP task force now sees them is given in the scheme on page *, which covers all BOP data flows. This report takes note of the messages which have been worked out in detail. In one respect the use of existing financial EDIFACT messages for collecting balance-of-payments data was proposed. This covers one very important data flow. For the other data flows new messages have been developed.

After a brief explanation of the BOP and the IIP concept, the document will describe the data requested by the BOP compilers and role of the parties involved in exchanging these BOP data. The adjusted or new EDIFACT messages used for reporting BOP data will be presented in this report.

 

According to the IMF Balance of Payments Manual, the balance of payments is a statistical statement, for a given time period, systematically summarizing the economic transactions of an economy with the rest of the world. Transactions, for the most part between residents (banks and non-banks) and non-residents, consist firstly of those involving goods, services, and income, and those classified as transfers (such as gifts). These transactions are summarized by the current account. Secondly, transactions consist of those involving financial claims on, and liabilities to the rest of the world. This concerns capital transactions of non-banks and of the banking sector as well as changes in the official reserves.

Closely related to the flow-oriented balance-of-payments framework is that of the stock-oriented international investment position (IIP). According to the IMF Balance of Payments Manual, the IIP is a statistical statement, compiled at a specified date such as year-end, of the value and composition of the stock of an economy’s financial assets or the economy’s claims on the rest of the world, and the value and composition of the stock of the economy’s liabilities to the rest of the world. A change in the position during any given period can be attributable to transactions (flows), to valuation changes or to other adjustments. In contrast, the balance-of-payments accounts reflect only transactions.

 

The balance of payments and the international investment position are compiled on behalf of the authorities. As is briefly described in the IMF Balance of Payments Manual, these statements serve an important use for national and international policy formulation, where ‘external’ aspects - such as payments imbalances and inward and outward foreign investment - play a leading role in economic and other policy decisions. Another use is for analytical studies such as the causes of payments imbalances and the relation with domestic saving and investment decisions, the relationships between merchandise trade and direct investment, aspects of international trade and services, and international banking flows and stocks.

 

The compilation of the BOP requires the reporting of transactions between residents and non-residents. In general terms this concerns the following information about these transactions. The key BOP data are in most cases necessary to allocate these transactions to the right period and the right category (for instance export of goods) and more specifically to make a geographical breakdown.

In most of the European countries (among others) the collection of information about transactions is based on the reporting of payments between residents and non-residents (general collection system, see paragraph 1.4.1). Moreover, in some of the national reporting systems additional information might be necessary for other, mainly checking purposes. One payment may involve several BOP transactions, for instance a payment on a loan may consist of interest and a redemption payment, which are treated differently in the BOP. A survey-based system is used in Anglo-Saxon countries and requires a combination of balance sheet data and aggregated transactions data (see paragraph 1.4.2).

Key data for BOP compilation in a general collection system:

the identity of the resident involved in the transaction(name and address, additional identification as SIREN (France), a VAT number or another national registration number)

the country of the non-resident partner to the transaction

the date of the (payment of the) transaction

total amount of the payment(possibly broken down, for instance in the case of a composite payment on a loan: interest and redemption payment)

currency

nature of the transaction, in code and/or in description (the harmonized coding system of EUROSTAT/OECD/IMF consists of more than 300 codes for BOP items); in some cases, such as outward direct investment, this might involve additional geographical data if the country of the payee differs from the country in which the direct investment takes place, which is relevant for the BOP)

the (industrial) activity of the resident involved in the transaction

Additional data BOP (the use can differ by country)

the identity of the non-resident involved in the transaction

the date of the BOP report

identification of the resident banking intermediary and of the banking intermediary of the non-resident

bank reference number

data on securities (e.g. ISIN number)

 

The compilation of the IIP requires the reporting by residents of their stocks of foreign assets and liabilities, by value and function.

In general the required IIP data are the following:

Key data for IIP:

the identity of the reporting resident

the debtor/creditor country

the value

the currency

the kind of stocks and flows

the date of the reported position

the type and sector of the reporting resident

Additional data IIP:

the identity of the non-resident

 

Reporting BOP and IIP data to the BOP compiler is paper-based, but increasingly with electronic messages. Messages can relate to transaction data or survey data as appropriate. As for transaction data the messages cover separate transactions reported by customers via a commercial bank or directly to the BOP compiler as well as banks’ own transactions and customer transactions reported by banks to the BOP compiler; reporting by the BOP compiler to international statistical bodies is also done in electronic format. However, at the moment the message standards used are still in many cases national, because they are established by BOP compilers, BOP-sector specific.

As the use of EDIFACT is spreading step by step - next to the trading sectors the banking community is getting into the act with EDI projects, nationally and internationally (SWIFT) - business administrations will increasingly be able to communicate in EDIFACT terms.

Business administrations are the source of BOP data. If these administrations increasingly use EDIFACT messages - and EDIFACT segments become integrated into these administrations - it would seem very efficient to use these segments or building blocks for reporting BOP data with EDIFACT messages. The use of this readily available information clearly saves costs. The change-over from paper-based reporting to reporting by electronic messages brings about even larger cost savings because manual work, with possible typing errors, is reduced to a large extent.

The banks too, which act as intermediaries in collecting BOP data, can save costs by using EDIFACT messages. This is certainly the case for banks which still handle paper forms. Cost saving is also possible in case banks already use electronic messages: EDIFACT is an international (UN) standard and can therefore be used in all countries for many applications. Being an international standard, EDIFACT can even stimulate the implementation of electronic data flows and thus also of electronic BOP reporting. Further, in the longer run the use of internationally exchanged EDIFACT BOP messages could save the banks (in a number of countries) the costs of collecting forms to be used for reporting external receipts (for this aspect see further section 1.6).

Last but not least the BOP compilers see advantages in obtaining the BOP information by using EDIFACT messages. Quicker and higher-quality reporting will be the result.

 

For the collection of BOP data basically two systems are used. Countries in continental Europe and Japan are among those operating a general collection system. A survey-based system is used in Anglo-Saxon countries.

 

In comparison with the survey-based system, the general collection system - direct reporting or ‘ticket’ system - calls for a (more) complete coverage of the transactions as regards the periodicity, the amounts involved and the geographical breakdown. This implies that all residents involved in transactions with non-residents are obliged to report about all these transactions (above a certain threshold value). In detail the following three main reporting flows relating to transactions with non-residents could be distinguished:

residents (non-banks) have to report about their individual transactions which are handled via resident bank accounts. In some countries the resident banks act as intermediaries for reporting of external payments and receipts to the BOP compiler. In other countries residents report directly to the BOP compiler.

residents have to report about their transactions with non-residents which occur via external bank accounts, current accounts held with a non-resident non-bank and via participation in international clearing systems. In these cases the residents report directly to the BOP compiler (often in aggregated form).

banks have to report about their nostro and loro accounts; changes in these accounts have to be justified by customer payments and receipts (both in aggregated form) and by their own transactions and portfolio transactions. This is all reported directly to the BOP compiler.

Apart from these transaction data flows, BOP compilers with a general collection system also collect survey data on the international investment positions. This mainly boils down to the following types of IIP data.

the detailed reporting by banks of their foreign assets and liabilities to establish the international banking position. These data are also used for reporting to the BIS.

the reporting by non-banks of their direct investments abroad and foreign direct investments in their resident enterprises as well as their financial foreign assets and liabilities such as trade credits and loans.

 

The survey-based system collects most of the data required for balance- of-payments purposes by a combination of balance sheet data and aggregated transactions data. Compared with a transaction-based system, the survey system adopts an integrated approach, collecting data for a range of economic statistics such as national accounts and money supply at the same time as balance-of-payments data. This avoids duplication, limits the information to be reported by suppliers and improves consistency across a range of economic statistics. Some data are reported monthly and some annually, but the general frequency of reporting is quarterly. Most data are collected under statute.

In detail the following three main types of reporting methods are used:

residents fill in balance sheet returns. This is the centrepiece of the survey system. Banks fill in a balance sheet return monthly which not only permits balance-of-payments figures to be taken directly but against which aggregated data, such as for direct and portfolio investment, can be cross-checked.

residents fill in aggregated transactions forms for those items which cannot be collected on the balance sheet return, for instance services data. For banks, their data on interest payments, direct investment income and services data are collected on one form which cross-checks for the appropriate items with a similar form completed for national accounts purposes.

For non-bank financial institutions, data on income and expenditure; transactions in financial assets and liabilities; and balance sheet information are collected in aggregate form through survey questionnaires.

administrative sources are used for items in the balance of payments, for instance official reserves.

 

Research into the possibilities of using EDIFACT messages for reporting BOP data must start with a data flow analysis. It has to be established exactly which data are being exchanged between the various parties. This has to be done for all data in the general collection system as well as in the survey-based system.

The following data flows could be distinguished:

from customers to banks (PAYORD/PAYMUL/PAYEXT and BOPINF)

from banks to the BOP compiler (BOPCUS and BOPBNK)

from enterprises to the BOP compiler (BOPDIR)

from BOP compiler to international statistical organisations and between BOP compilers (GESMES/CB)

between banks (FINPAY)

These dataflows could be captured with the above-mentioned EDIFACT messages, which are presented in the scheme at page 12. Examples of these messages using fictitious business transactions will be given in Chapter 2. Full details of the messages will be given in the Annexes.

For the sake of clarity, the use of (one of) these messages is fully optional. All messages are independent and could be used as such. For instance, although PAYORD and BOPCUS are linked, it is not necessary to use them both.

 

 

Message sent by customer to bank for making a payment by debiting his account, which for BOP purposes must also include information on, for instance, the nature of the transaction.

The existing EDIFACT message PAYORD is a good starting point, but a few segments had to be added to accommodate BOP requirements. In agreement with CEFACT/D6 Finance (CEFACT is the EDI Expert Group for financial messages; D6 is a group responsible for the worldwide coordination of these activities) a solution was found by changing the PAYORD message in such a way that BOP information on the nature of the transaction is included in a structured way. The same is true of the EDIFACT messages PAYEXT (extended payment order message) and PAYMUL (multiple payment order message). For presentational reasons, further detailed references are only made to the PAYORD message.

 

Message sent by the customer to his bank to give information on the nature of the transaction when his account is credited because of a receipt from a non-resident (crediting information could be received by the bank via the EDIFACT messages CREADV or CREEXT: when we mention CREADV in this report we mean CREADV or CREEXT). The information received from the customer by the bank via the message BOPINF - which is complementary to the crediting information obtained via the message CREADV - is to be forwarded to the BOP compiler together with the BOP relevant crediting information. The information to be forwarded to the BOP compiler is to be transmitted via the message BOPCUS. In jargon the sending of the CREADV message to the client and the return of the BOPINF message to the bank is called the home loop. In the ideal case the return of the BOPINF message could be dropped (see paragraph 1.6).

 

Message sent by banks to the BOP compiler for reporting - one by one - individual cross-border customer transactions (debit and credit; cross-border means transactions between residents and non-residents). Actually, this transaction information can be distilled - one by one - from PAYORD/PAYMUL/PAYEXT and BOPINF messages, respectively.

 

Message sent by enterprises (non-banks) to the BOP compiler to supply information on amounts received from non-residents via resident banks; this is an alternative route to sending a BOPINF message. Or, as is the case in France, to report on all their transactions, payments and receipts (Déclarants Directs Généraux or DDG’s). This part is dealt with in Block 1 of the message.

This message could also be used for reporting on settlements via external bank accounts, current accounts held abroad with non-banks or participation in an international clearing system (in the case of clearing operations gross information has to be supplied). This part is also dealt with in Block 1 of the message.

Further, this message could also be used for reporting results of questionnaires by enterprises directly to the BOP compiler. This function is certainly of use in the survey system (operational in, for instance, the Anglo-Saxon countries), but will also be used by BOP compilers with a general collection system. In addition, it can be used for reporting by non-banks on their foreign assets and liabilities. Both these purposes are dealt with in Block 2 of the message.

 

Message sent by banks to BOP compiler for reporting the banks’ own transactions and portfolio transactions. This message might also be used for reporting the assets and liabilities positions of the banks.

 

Message sent by BOP compilers for reporting aggregated BOP data to international statistical bodies such as BIS, ECB, EUROSTAT, IMF and OECD. This message can also be used for exchanging BOP data between BOP compilers.

 

A Customer Payment Message sent by or on behalf of the ordered bank, directly or through a correspondent, to the beneficiary’s bank, to inform the beneficiary’s bank of a payment in its favour to a specified amount. It further instructs the bank to remit these funds to the beneficiary. This message could in future also include BOP information. This report does not address the FINPAY message.

The above mentioned EDIFACT messages cover the following data flows:

In the longer run the use of EDIFACT messages could bring about important cost savings for banks and customers. For in a ideal situation it is thought possible that a customer will in most cases no longer have to report about a cross-border receipt. This assumes that its resident bank has all the necessary BOP information, which is supplied by the foreign payor in an EDIFACT message received via SWIFT or another international network. The customer no longer has to supply this information (via BOPINF) and the resident bank will pass the information on to the national BOP compiler. In summary, the home loop would no longer be necessary.

However, in order to eliminate the home loop, a harmonized BOP data collection system has to be in operation and an international network such as SWIFT has to permit the transmission of the necessary BOP information in its messages.

Moreover, in some cases it might still be necessary to check the BOP information with the customer (for instance, in the case of merchanting trade: a transaction identified as imports by the foreign payor would in normal cases be exports for the customer; however, it could also be merchanting exports).

More in general, data confidentiality rules might at the moment not allow the sending of individual transaction data to third parties, which is necessary for eliminating the home loop. Legal regulations in a number of countries provide that BOP information supplied can only be used for national purposes. Therefore, customers cannot be obliged to pass on BOP information to other countries. Unless a customer allows information to be passed on a voluntary basis, the internationally exchanged EDIFACT message does not contain all relevant BOP information. In that case the bank in the other country cannot report directly about the receipt to the BOP compiler, but the foreign customer still has to report the receipt and supply information about, for instance, the underlying nature of transactions. To save on the so-called home loop, it would be necessary that harmonized data secrecy rules are introduced. These rules, which will probably be developed by the EU should take into account that confidentiality, supported by sanctions, is essential to the quality of the data.

Other aspects to facilitate the exchange of BOP information with other countries are, among others, the harmonisation of thresholds and codification in the different countries.

 

Change requests have been formulated for existing EDIFACT messages and new EDIFACT messages have been developed which can be used to collect all BOP information for all BOP data statistical systems (general collection or survey-based system). This implies that the messages take into account all requirements.

However, to secure approval of all countries, the segments of the messages are in general made conditional (optional). As long as the data collection systems are not harmonised this approach can accommodate all different national requirements without obliging the users in different countries to report more than is required by the present national regulations. If BOP compilers wish to ensure that they receive the required BOP information, the conditional segments of the message will have to be made mandatory by national guidelines. If, in the longer run the data collection systems in Europe are harmonised the segments might be made mandatory by ECB/Eurostat guidelines.

 

An EDIFACT message can be presented in several ways. One of them is a listing of the segments used. Another is a branching diagram which provides a structured representation of the segments, that is, their sequence and in some cases the linkages. Examples of such a branching diagram are given in the Annexes.

For explanation the branching diagram of PAYORD (see annex-1) is used.

The diagram starts with standard segments such as UNH (message header), BGM (beginning of the message) and DTM (date of the message) and ends with CNT (Control Total) and UNT (message trailer). The segments in between are specific to the message. Each segment is ‘boxed’.

Underneath each segment tag, in the bottom left corner of the box, is shown either the indication C for conditional or M for mandatory.

There could be repeating segments. The number of occurrences is shown in the bottom right corner of the box (this number is a maximum). For instance, the segment BUS has one occurrence.

Some segments stand alone. Others are grouped together because segments are interlinked; for instance in BOPDIR, in the case of the segment NAD (Name and Address of the declarant) of Group 2 it could be necessary to have the name of a contact person (segment CTA) at the declarant. If the indicated number of the occurrences of a group is more than one (for instance, in the case of Group 2) the process may have to repeat the number of loops by the required number before moving on to the next stand-alone segment or group of segments.

Segments may contain one or several related user data elements. A data element may be either simple (single data item) or composite (consisting of several composite data elements). An example of a composite data element is a qualifier, which gives a specific meaning to a data element. For instance, the segment COM (Communications contacts) has two composite data elements. The first indicates a communication number, the second the communication channel qualifier which specifies the number; the number could be a fax number specified by the qualifier FX.

All segments and data elements are published in approved directories. In addition, all qualifiers are published in a UN/EDIFACT code list.

 

/ acknowledgment message

Some reports transmitted previously can be wrong. In that case a correction (either a change, replacement or a deletion) ought to be notified. There are different ways to do this.

 

FINCAN is a message from the customer to communicate the cancellation of a financial message, such as PAYORD, PAYEXT, PAYMUL and DIRDEB, to the ordered bank. If in such a case a BOPCUS message (by the bank) or BOPDIR message (by the customer) had already been sent to the BOP compiler, a message has to be sent to communicate the cancellation.

A first possibility is to send a similar message (BOPCUS/BOPDIR) using the BGM segment of the message to communicate the cancellation or replacement of the previous message. The BGM segment contains a data element (1225) which can be used to specify its function. The most relevant possibilities are:

the message concerns a cancellation which deletes information sent in a previous (referenced) message;

the message is an original one;

the message contains a replacement which replaces information sent in a previous (referenced) message;

duplication of a previous (referenced) message.

References to the original message are made in the RFF segment.

A second possibility is to use the APERAK message.

 

APERAK is an acknowledgment message originated by the receiver to inform the message issuer either that there is an error in the previous message or that the previous message is acknowledged (i.e. no error). APERAK identifies the original message, can pinpoint the area of the error and allows a free-text explanation of the error. The receipt of an APERAK indicating an error in a message should trigger an investigation by the message recipient. A corrected BOPCUS/BOPDIR message should be sent to replace the original message.

 

The DIRDEB message can be used in case of direct debiting procedures whereby the payee (the creditor) initiates the payment by sending the DIRDEB message to its bank to instruct it to claim the amount receivable from a debtor. The creditor’s bank forwards this message to the debtor’s bank. The debtor will be informed by its bank via a debit advice (DEBADV) that its account has been debited. The creditor will be informed by its bank via a credit advice (CREADV) that its account has been credited. There are two options for reporting the payment initiated by the DIRDEB message, depending on the type of collection system for balance of payments:

Option A: The creditor and/or debtor uses a BOPINF message to inform the BOP compiler (indirectly) via its banks. Reference could be made to the CREADV and DEBADV, respectively. In the case of the creditor this is the same procedure as if the payment would be initiated by a payord.

Option B: The creditor and/or debtor uses a BOPDIR message to inform the BOP compiler directly.

 

Under current paper-based reporting systems, much of the information provided by banks and enterprises to the BOP compiler is subject to some form of security classification. Similarly, certain information which currently passes between national BOP compilers and between them and other transnational bodies (e.g. Eurostat) sometimes needs to be protected prior to publication. For this reason, it is considered important to pay attention to the security aspects regarding the use of EDIFACT messages for BOP purposes. However, it is stressed that the responsibility for the implementation of the appropriate security measures lies with the project teams in charge of the implementation of EDIFACT reporting systems in each country.

 

Sending data involves exposure to a number of risks. A summary of these risks, the resulting user requirements and some suggested solutions are shown in tabular form below:

Some of these threats are intentional and may lead to fraud or deliberate mis-information. Others may be accidental or co-incidental, for example, message corruption in the course of transmission.

 

Various possible levels of security are identified. For example, individual transactions (via PAYORD/PAYEXT) may attract a high level of security because of the market-sensitive nature of the data being transmitted, though this will ultimately be a commercial decision. Similarly, enterprises which send BOP data directly to the BOP compiler (via BOPDIR) might wish to have these data protected from casual or accidental exposure, though the degree of protection offered under these circumstances might not be as great as in the first instance. The degree of protection might therefore be of lower quality for the sake of both simplicity of operation and costs. Messages between BOP compilers and transnational bodies (such as Eurostat and the IMF) generally deal with published (or publishable) aggregated data and probably will need no protection at all. However, certain statistics that are not published, or have not yet been published, may need some protection. Confidentiality may vary between countries; much will depend on the perceived sensitivity of the data. BOP compilers may also feel a need for security for their own messages. Different techniques permit different levels of security; for instance, security headers and trailers offer end-to-end security which is different from, and complementary to, any network security. Or the data themselves might be encrypted using one of the numerous solutions available on the market.

 

Security headers and trailers can be used at message level between the UNH and the UNT segments to aid authentication, message integrity and sequencing. They can also communicate the nature of message security (if any) incorporated in the main body of the message. In the design of the EDIBOP messages, use is already made of hash totals in the CNT segments and the number of segments in the UNT segments.

The message APERAK is being considered since this would help BOP compilers to identify and correct errors, and it would also aid message sequencing (see also under 1.10).

 

 

The purpose of the additional part of the PAYORD message and the new messages BOPINF, BOPCUS, BOPDIR, BOPBNK and GESMES/CB is to collect and forward Balance-of-Payments (BOP) and International Investment Position (IIP) data. Full details of these messages are given in the Annexes. For an understanding of the structure and content of these messages and how they can be used each message will be illustrated with an example. The examples describe fictitious simple business transactions which are given in a narrative. The next step is to indicate the location of the details of the business transaction in EDIFACT segments; it concentrates on the BOP-relevant segments. The issue of conditional or mandatory statements of the segments is not addressed; national guidelines will be explicit about this.

A PAYORD message is sent by a payor to the ordered bank, to instruct this bank to debit an account it services for the payor, and to arrange for the payment of one specified amount to the beneficiary in settlement of the referenced business transaction(s).

The EDI BOP group agreed with CEFACT/D6 Finance some years ago to adjust this PAYORD message to cater for additional BOP information on the transaction(s), especially the nature of the transaction, which is necessary for the compilation of the balance of payments. This additional BOP information is combined in group 6 consisting of segments: GIS-MOA-LOC-NAD-RCS-FTX.

(References are made to PAYORD, release 99A)

Narrative

On October 7, 1998, Real Estate Investments NV, Droogdok 6, Amsterdam instructs (ID number: 9087) Financiële Bank NV, Amsterdam to pay on October 14, 1998, USD 1,800,000 to Hessen Bank AG, Frankfurt, in favour of account number 547567 of Baufinanz GmbH, Kölner Allee 524, Frankfurt.

Real Estate Investments NV’s USD-denominated account number 123456 serviced by Financiële Bank NV is to be debited.

Payments details to be sent to Mr Franz are ‘Chalets Suisse’.

The transaction concerns the purchase of real estate located in Switzerland from a real estate company in Germany.

This international transaction has to be reported to the BOP compiler; Real Estate Investments NV allows BOP data to be forwarded to Germany.

Details EDIFACT segments

Execution date: October 14, 1998 DTM

Transaction details: Chalets Suisse FTX

Amount: 1,800,000; currency: USD Gr 2 MOA

Ordered bank: Financiële Bank NV Gr 3 FII (1^st occurrence)

acct holder: Real Estate Investments NV

acct number: 123456

currency denomination: USD

Beneficiary’s bank: Hessen Bank AG FII (2^nd occurrence)

acct holder: Baufinanz GmbH

acct number: 547567

Payor: Real Estate Investments NV, Gr 4 NAD (1^st occurrence)

Droogdok 6, Amsterdam

ID number: 9087

Payee: Baufinanz GmbH, NAD (2^nd occurrence)

Kölner Allee 524, Frankfurt

Contact person: Mr Franz CTA

International transaction, reason of payment

reported by bank, forwarding of BOP data

abroad authorized: Gr 6 GIS: 62

Amount: 1,800,000; currency: USD Gr 6 MOA ¹

Geographical detail:

direct investment country Gr 6 LOC, qualifier = 163

Switzerland

Nature of trans.(purchase of real estate),coded RCS

Nature of transaction (ditto), clear text FTX

 

A BOPINF message, specially designed for BOP reporting purposes, is sent by a payee to its bank on receipt of an individual amount as a settlement of a transaction with a non-resident about which the BOP compiler has to be informed via the payee’s bank.

It is assumed that the payee is informed about the receipt by a CREADV message. The GIS segment in the CREADV message can be used by the bank of the payee for requesting additional BOP data from the payee. As far as this message contains relevant BOP data (for instance, counterparties and amount) the payee can - by referring in the BOPINF message to the CREADV message - refrain from reporting this data to its bank. The other main part of the BOPINF message relates to additional BOP information which is catered for by a special group (segment group 4). For reporting to the BOP compiler (via the BOPCUS message) the payee’s bank has to combine the CREADV message (that is referenced in segment group 3) and the BOPINF message.

Narrative

On February 10, 1992, Chemie Finance NV, World Trade Center 637, Amsterdam (ID number: 75325), is credited with DEM 2,400,000 by Financiële Bank NV, Amsterdam; the account number of Chemie Finance NV serviced by Financiële Bank NV, Amsterdam is 987654. The Chemie Finance NV is informed about this receipt by CREADV no. 1890.

The payor is Chemie AG, Salzburger Platz 2, Vienna, which ordered Kaiser Bank, Vienna, to debit its account, account number 4893728, for DEM 2,400,000.

The payment refers to Contract no. 678.

The transaction concerns a composite payment on a loan extended by Chemie Finance NV, Amsterdam, to Chemie AG, Vienna; part of the payment relates to an interest payment, for DEM 400,000, while the other part relates to a redemption, for DEM 2,000,000.

This international transaction has to be reported to the BOP compiler.

Details EDIFACT segments

Reporting enterprise:

Chemie Finance NV Gr 2 NAD¹

World Trade Center 637

Amsterdam

ID number: 75325

First loop, handled by RFF segment

BOPINF is triggered by CREADV no. 1890 Gr 3 RFF, qualifier ALD

Execution date of CREADV: February 10, 1992 Gr 3 DTM

Nested loop, handled by RCS segment Gr 4 (1^st occurrence)

Nature of transaction (interest), coded Gr 4 RCS

Nature of transact. (interest), clear text Gr 4 FTX

Amount: 400,000; currency: DEM Gr 4 MOA

Nature of trans. (redemption), coded Gr 4 RCS

Nature of trans.(redemption), clear text Gr 4 FTX

Amount: 2,000,000; currency: DEM Gr 4 MOA

CREADV (relevant parts; to be combined with BOPINF to create BOPCUS)

reference number of CREADV: no. 1890 BGM

Amount: 2,400,000; currency: DEM Gr 2 MOA

Payee’s bank: Financiële Bank NV Gr 3 FII (1st occurrence)

acct holder: Chemie Finance NV

acct number: 987654

Payor’s bank: Kaiser Bank Gr 3 FII (2^nd occurrence)

acct holder: Chemie AG

acct number: 4893728

Payor: Chemie AG, Gr 4 NAD

Salzburger Platz 2

Vienna

A qualifier (value = 64) makes clear Gr 6 GIS

that a BOP complement of information is requested.

A BOPCUS message, specially designed for BOP reporting purposes, is to be used by a bank to report its individual customer transactions (payments and/or receipts) over a specific period to the BOP compiler.

This message could be constructed with relevant segments of a PAYORD message, if it concerns a payment, or a combination of the relevant parts of the corresponding CREADV and BOPINF messages, if it concerns a receipt. The segments to be copied out of PAYORD and/or BOPINF/CREADV relate among others to the additional BOP information, which, as in the other two messages, is catered for by a special group. The message can contain up to 99999 transactions, which is - transaction by transaction - handled by a LIN (line item) segment.

Narrative

To comply with the monthly reporting obligation, the Financiële Bank NV, Amsterdam, has to report all its individual customer transactions in that month. To keep matters simple, it is assumed that there was one payment, as described in the PAYORD narrative, and one receipt, as described in the BOPINF narrative. The details of these narratives will be used in the BOPCUS message.

Details EDIFACT segments

Reporting period DTM

Reporting bank (Financiële Bank NV) Gr 2 NAD

FIRST OCCURRENCE (reporting of the payment) Gr 3 LIN (line number = 1)

Beneficiary’s bank: Hessen Bank AG Gr 3 FII

acct holder: Baufinanz GmbH

acct number: 547567

Reference to PAYORD message Gr 4 RFF, qualifier = AEK

Date of PAYORD message Gr 4 DTM

Payor: Real Estate Investments NV, Gr 5 NAD (1^st occurrence)

Droogdok 6, Amsterdam

ID number: 9087

Payee: Baufinanz GmbH Gr 5 NAD (2^nd occurrence)

Kölner Allee 524

Frankfurt

Contact person: Mr Franz Gr 5 CTA

Amount: 1,800,000¹ ; currency: USD Gr 6 MOA

Nature of trans.(purch. of real est.),coded Gr 7 RCS

Nature of transaction (ditto), clear text Gr 7 FTX

Geographical detail: direct investm.country Gr 7 LOC, qualifier = 163

Switzerland

SECOND OCCURRENCE (report. of the receipt) Gr 3 LIN (line number = 2)

Ordered bank: Gr 3 FII

Kaiser Bank

acct holder: Chemie AG

acct number: 4893728

Reference to BOPINF message Gr 4 RFF, qualifier = ALC

Date of BOPINF message Gr 4 DTM

Payee: Chemie Finance NV Gr 5 NAD (1^st occurrence)

World Trade Center 637, Amsterdam

ID number: 75325

Payor: Chemie AG, Gr 5 NAD (2^nd occurrence)

Salzburger Platz 2

Vienna

Amount: 2,400,000 ¹ ; currency: DEM Gr 6 MOA

Nature of transaction (interest), coded Gr 7 RCS (1^st occurrence)

Nature of trans. (interest), clear text Gr 7 FTX

Amount: 400,000 ¹; currency: DEM Gr 7 MOA

Nature of trans. (redemption), coded Gr 7 RCS (2^nd occurrence)

Nature of trans.(redemption), clear text Gr 7 FTX

Amount: 2,000,000 ¹; currency: DEM Gr 7 MOA

A BOPDIR message, specially designed for BOP purposes, is - in a number of countries - to be used by a non-bank to report on its external transactions and foreign positions directly to the BOP compiler.

Direct reporting can be done in the following cases* :

external transactions via a resident bank

transactions via accounts held with non-residents

bank accounts

current accounts held with a non-bank and participation in an international clearing system

foreign assets and liabilities of a resident non-bank

BOP-related surveys (on behalf of, for instance, Anglo-Saxon countries)

Each of the five cases will be clarified by an example. A BOPDIR message can incidentally be used for more than one of the above-mentioned cases at the same time, which applies for instance to the French system of ‘Déclarants Directs Généraux’.

To accommodate these multiple flows, the structure of the BOPDIR consists, apart from the context segments, of the following two blocks:

The first block covers firstly external transactions via a resident bank (case a). The design of this block allows for reporting on up to 999 resident accounts, each specified by the bank where the account is held (segment FII in Group 3).

Furthermore, for each resident account up to 9999 transactions can be reported; for each transaction data has to be given on the nature of the transaction (in code and in clear text; RCS and FTX segments, respectively), the amount (MOA segment), the counterparty (NAD segment) and, if any, geographical detail (LOC segment).

Per transaction, reference (RFF segment) could be made to, for instance, a PAYORD message; the link to that PAYORD message could be important if the transaction is not reported via that message - indicated by an exclusion code - but via BOPDIR.

The first block covers secondly transactions via accounts with non-residents (cases b1 and b2). This block allows for reporting on up to 999 external accounts, each specified in the ATT segment by its type (external bank account, current account held with a non-resident non- bank, a.o.) and by the party where the account is held.

The party could be a bank (in principle, the FII segment is used; if only the name of the bank is requested, the NAD segment can be used as well) or a non-bank (for instance, an enterprise; a NAD segment is used). For each account the opening and the closing balances could be given (in the MOA segment) and/or the currency (CUX segment). For each account up to 9999 transactions can be reported. Each transaction has to be specified by its nature (in code and in clear text; in RCS and FTX segments, respectively), the amount (MOA segment), the counterparty (NAD segment) and, if necessary, country information (LOC segment). Furthermore, for each transaction a reference (RFF segment) could be given.

The second block covers the reporting of foreign assets and liabilities (IIP data) of a resident non-bank (case c) and the reporting of BOP-related survey results (case d). The segment at the top of this block, the RFF segment, distinguishes the kind of report form or survey in code. The second level addresses the columns or rows of the report form indicated at the first level or the questions of a survey; this again in code (RCS segment) and in clear text (FTX segment). Furthermore, for each column/row/question, the structure allows reporting of up to 9999 stocks or flows, that is, their values, in the MOA segment, and the corresponding counterparty/country in the NAD segment. This will be adequate for, say, the geographical breakdown of the holders of, for instance, short-term liabilities of a non-bank enterprise.

Narrative 1 (domestic bank accounts)

On January 16, 1992 Exim SA, Boulevard Henri Dunant 87, Reims, instructs Banque d’Alsace SA, Reims, to pay on January 21, 1992, GBP 3,200,000 to Merchants Bank Ltd, Newcastle, in favour of account number 3215984 of Electronic Instruments Ltd, Harbour Road 56, Newcastle. Exim SA account number 5893729 serviced by Banque d’Alsace SA is to be debited. The transaction concerns a purchase of electronic equipment.

As Exim SA, Reims (SIREN number 999999999), is a ‘déclarant direct général’ this transaction is not reported via the PAYORD message 2345, which is used for ordering the payment; this procedure is indicated in the GIS segment of that message 2345 by a qualifier for direct reporting (= 65).

Further, on January 17, 1992 Exim SA, Reims, is credited with ITL 5,800,000 by Banque de Reims SA, Reims; the account number of Exim SA serviced by Banque de Reims SA is 2783948. The payor is Electronica Toscane S.p.A, Via Milano 32, Genoa. The transaction concerns a sale of electronic equipment.

Details EDIFACT segments

Reporting institution: Exim SA Gr 2 NAD

SIREN number: 999999999

Gr 3 RFF (1^st occurrence)

Intermediating bank: Banque d’Alsace SA Gr 3 FII

acct number: 5893729

Nature of trans.(purch. of goods), in code Gr 4 RCS

Nature of transact. (ditto), in clear text Gr 4 FTX

Counterpart(payee): Gr 4 NAD

Electronic Instr. Ltd

Newcastle

United Kingdom

Reference to bank transaction number Gr 5 RFF

Date of the transaction Gr 5 DTM

Amount: 3,200,000¹; currency: GBP Gr 6 MOA

Gr 3 RFF (2^nd occurrence)

Intermediating bank: Gr 3 FII

Banque de Reims SA

acct number: 2783948

Nature of trans. (sale of goods), in code Gr 4 RCS

Nature of transact. (ditto), in clear text Gr 4 FTX

Counterpart (payor): Gr 4 NAD

Electronica Toscane

Genoa

Italy

Reference to bank transaction number Gr 5 RFF

Date of the transaction (receipt) Gr 5 DTM

Amount: 5,800,000 ¹ ; currency: ITL Gr 6 MOA

Narrative 2 (external bank account)

Finland Paper Industries, Hermannivägen 345, Helsinki (ID number: 2604), has an ATS bank account at the Linzer Bank AG, Vienna, Austria; its account number is 348970. To comply with the quarterly reporting obligation, Finland Paper Industries has to report to the BOP compiler the opening and closing balance of that external bank account as well as the transactions which have been executed via that account. The opening balance at October 1, 1998 is ATS 1,000,000. On November 14, 1998 Finland Paper Industries instructs the Lahti Bank Oy, Helsinki, to transfer ATS 300,000 to its account at the Linzer Bank AG; Finland Paper Industries’ account number 98765 serviced by the Lahti Bank Oy is to be debited. Furthermore, on December 2, 1998 Finland Paper Industries’ Linzer Bank AG bank account is credited with ATS 150,000. The payor is Drückerei GmbH, Mozartstraße 12, Graz, which instructed Kaiser Bank AG, Graz to debit its account, account number 4499887, for ATS 150,000. This transaction concerns a payment for the sale by Finland Paper Industries of paper. Except for these two transactions, Finland Paper Industries’ external bank account at the Linzer Bank AG is not debited or credited in the fourth quarter of 1998, so the closing balance at December 31, 1998 is ATS 1,450,000.

Details EDIFACT segments

Reporting period (4^th quarter 1998) DTM

Reporting institution : Gr 2 NAD

Finland Paper Industries

Hermannivägen 345

Helsinki

ID number: 2604

Gr 3 RFF (1^st occurrence)

Type of account (extern.bank acct),in code Gr 3 ATT

Bank where external bank acct is held:

Linzer Bank AG, Gr 3 FII (or NAD if only the name is
requested)

Vienna

acct number: 348970

Opening balance (1,000,000) Gr 3 MOA (1^st occurrence)

Closing balance (1,450,000) Gr 3 MOA (2^nd occurrence)

currency denomination: ATS Gr 3 MOA or CUX

Nature of trans.(transf.own acc.), in code Gr 4 RCS (1^st occurrence)

Nature of transact.(ditto), in clear text Gr 4 FTX

Domestic bank involved in trans: Gr 4 FII

Lahti Bank Oy

Helsinki

acct number: 98765

Domestic bank ref. (or PAYORD ref.) Gr 5 RFF

Execution date transfer (date of PAYORD) Gr 5 DTM

Amount transferred: 300,000; currency: ATS Gr 6 MOA

(receipt)

Nature of trans. (sale of paper), in code Gr 4 RCS (2^nd occurrence)

Nature of transact. (ditto), in clear text Gr 4 FTX

Country of counterpart (Austria) Gr 4 LOC

Amount (receipt): 150,000; currency: ATS Gr 6 MOA

Narrative 3 (current account held with a non-resident non-bank)

Alcazar Computers, Plaza del Bilbao 32, Madrid (ID number: 19928), holds a current account with its affiliated company, Alcazar Software S.p.A, Via Mestre 57, Milan. To comply with the semi-annual reporting obligation, Alcazar Computers, Madrid, has to report to the national BOP compiler the opening and closing balance of that current account as well as the transactions which have been executed via that account. The opening balance of the current account on July 1, 1998 is USD 570,000. On August 31, 1998 Alcazar Computers, Madrid, instructs Alcazar Software, Milan, to pay on September 16, 1998 USD 125,000 to Electronica Toscane, Genoa. This payment concerns a purchase of computer parts; reference Invoice 2356. Except for this transaction, Alcazar Computers, Madrid did not use its current account at Alcazar Software, Milan in the second half of 1998, so the closing balance at December 31, 1998 is USD 445,000.

Details EDIFACT segments

Reporting period (second half 1998) DTM

Reporting institution: Gr 2 NAD

Alcazar Computers

Plaza del Bilbao 32

Madrid

ID number: 19928

Gr 3 RFF (1^st occurrence)

Type of account (current account), in code Gr 3 ATT

Non-bank at which current account is held:

Alcazar Software Gr 3 NAD

Via Mestre 57

Milan

Opening balance (570,000) Gr 3 MOA (1^st occurrence)

Closing balance (445,000) Gr 3 MOA (2^nd occurrence)

currency denomination: USD Gr 3 MOA or CUX

Nature of trans.(purch. of goods), in code Gr 4 RCS

Nature of transact. (ditto), in clear text Gr 4 FTX

Country of counterpart (Italy) Gr 4 LOC

Reference (Invoice 2356) Gr 5 RFF

Amount: 125,000; currency: USD Gr 6 MOA

Narrative 4 (foreign assets and liabilities)

Baufinanz GmbH, Kölner Allee 524, Frankfurt (ID number: (30739), is a company active in international trade and finance. To comply with the monthly reporting obligation, Baufinanz GmbH has to report to the national BOP compiler about all its foreign assets and liabilities. In the report the company has to differentiate between trade credit-related and other assets and liabilities. As for trade credit, Baufinanz GmbH extended one trade credit in November 1998 to an affiliated company in Italy: DEM 137,500 and received one trade credit from a non-affiliated company in the United Kingdom: GBP 56,000. Further, in November 1998 Baufinanz GmbH received one non-trade credit related loan: ATS 132,000 from a bank in Austria. The reporting involves several loops and innerloops.

Details EDIFACT segments

Reporting period (November 1998) DTM

Reporting institution:

Baufinanz GmbH Gr 2 NAD

Kölner Allee 524

Frankfurt

ID number: 30739

Type of report form (trade credit) Gr 8 RFF (1^st occurrence)

Assets (trade credit ext.;aff. firm) Gr 9 RCS (1^st occurrence)

Amount (137,500); currency (DEM) Gr 10 MOA (1^st occurrence)

Debtor/creditor country (Italy) Gr 10 LOC

Liabs (trade credit rec.;non-aff. firm) Gr 9 RCS (2^nd occurrence)

Amount (56,000); currency (GBP) Gr 10 MOA (1^st occurrence)

Debtor/creditor country (United Kingdom) Gr 10 LOC

Type of report form (non-trade credit) Gr 8 RFF (2^nd occurrence)

Liabilities (bank loan received) Gr 9 RCS (1^st occurrence)

Amount (132,000); currency (ATS) Gr 10 MOA (1^st occ)

Debtor/creditor country (Austria) Gr 10 LOC

Narrative 5 (BOP-related surveys)

The Central Statistical Office in the United Kingdom collects on a quarterly basis such data as statistical information about overseas transactions in royalties and other services of UK companies for use in compiling the UK balance of payments. The survey form addresses several issues regarding balance-of-payments; if a question does not apply, the box is left empty. Electronic Instruments Ltd, Harbour Road 56, Newcastle (ID number: 397622), has a company in Austria which is an overseas branch. In the third quarter of 1998 the parent company received from this overseas branch GBP 25,000 as a payment for royalties. On the other hand, Electronic Instruments Ltd paid FRF 30,000 for services rendered by an unrelated company in France.

Details EDIFACT segments

Reporting period (3^rd quarter 1998) DTM

Reporting institution: Gr 2 NAD

Electronic Instruments Ltd

Harbour Road 56

Newcastle

ID number: 397622

Type of report form (royalties etc) Gr 8 RFF (1^st occurrence)

Question 1 (related, royalties, rec.) Gr 9 RCS (1^st occurrence)

Amount (25,000); currency (GBP) Gr 10 MOA (1^st occurrence)

Country (Austria) Gr 10 LOC

Question 8 (unrel.,other serv, paid) Gr 9 RCS (8^th occurrence)

Amount (30,000); currency (FRF) Gr 10 MOA (1^st occurrence)

Country (France) Gr 10 LOC

(questions 2 to 7 not applicable)

A BOPBNK message, specially designed for BOP purposes, is to be used by a bank to report on its own external transactions, securities transactions executed on behalf of its customers, and on its assets and liabilities position.

The main part of the message can accommodate up to 999 kinds of natures of transaction or types of position (in code and clear text; RCS segment, group 4 and FTX segment, respectively). An example of the nature of a transaction is: a foreign exchange transaction; an example of a type of position is: loans extended to non-resident non-banks. Within the flexible framework of this message, the nature of transaction or type of position can be specified further.

The MOA segment in group 3 could be made up of the opening and closing balance of an account with additional information about the currency in which the account is denominated in this segment or in the CUX segment. The LOC segment in group 3 could be used to report on (loro) accounts per country.

Per nature of transaction, or position, up to 9999 transactions can be specified by amount (MOA segment, group 5) and by counterparty. This counterparty can be identified by the NAD segment or - less specifically - by country of domicile of the counterparty (LOC segment). In the case of securities transactions, specifications per security type can be given in group 6 (GIR - QTY segments). In stead of the MOA segment in group 3, the MOA segment in group 5 could incidentally also be used for stating the opening/closing balance and/or the currency denomination.

Narrative 1 (bank’s own transactions)

To comply with the monthly reporting obligation, the Kaiser Bank, Vienna (ID number: 99988), has to report about all its own transactions in a month. In September 1998 the Kaiser Bank extended a long-term loan of DEM 750,000 to the Banque d’Alsace, Reims (Austrian ID number: 756). This implies that the balance of the nostro account of the Kaiser Bank decreased from DEM 8,750,000 to DEM 8 mln. In addition it sold on behalf of the Linzer City Pension Fund ATS 2,087,500 of 6ź % World Bank bonds (nominal value: NLG 400,000; ISIN number: NL0000203651) to an institutional investor in Italy.

This implies that the balance of the loro account of the Kaiser Bank with Italy decreased from ATS 12,100,000 to ATS 10,012,500.

Details EDIFACT segments

Reporting period (September 1998) DTM

Reporting institution: Gr 2 NAD segment

Kaiser Bank,

Vienna

ID number: 99988

FIRST OCCURRENCE (nostro acc. in DEM) Gr 3 RFF

Currency: DEM Gr 3 CUX

Nature of trans.(open.balance nostro acc.) Gr 4 RCS (first occurrence)

Amount: 8,750,000 ; currency: DEM Gr 5 MOA

Nature of trans. (LT loan extend.to a bank) Gr 4 RCS (second occurrence)

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 750,000 ¹ ; currency: DEM Gr 5 MOA

Counterparty: Gr 5 NAD

Banque d’Alsace, Reims

Austrian ID number: 756

Nature of trans. (closing bal.nostro acc.) Gr 4 RCS (third occurrence)

Amount: 8,000,000 ¹ ; currency: DEM Gr 5 MOA

SECOND OCCURRENCE (loro acc. with Italy) Gr 3 RFF

Currency: ATS Gr 3 CUX

Country: Italy Gr 3 LOC

Nature of trans.(opening bal. loro acc.) Gr 4 RCS (first occurrence)

Amount: 12.100,000 ¹ ; currency: ATS Gr 5 MOA

Nature of transaction:

(sale World Bank bonds) Gr 4 RCS (second occurrence)

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 2.087,500 ¹; currency: ATS Gr 5 MOA (1^st inner loop)

Securities specification

ISIN number: NL0000203651 Gr 6 GIR

nominal value: NLG 400,000 Gr 6 QTY

Counterparty: instit. investor in Italy Gr 5 LOC

Nature of trans.(closing bal. loro acc.) Gr 4 RCS (third occurrence)

Amount: 10.012,500 ; currency: ATS Gr 5 MOA

An alternative to structuring the details of the narrative as far as the LT loans are concerned is the following:

Details EDIFACT segments

FIRST OCCURRENCE (short term loans) Gr 3 RFF

Opening balance nostro acc.(DEM 8,750,000) Gr 3 MOA (1^st occurrence)

Closing balance nostro acc.(DEM 8,000,000) Gr 3 MOA (2^nd occurrence)

Nature of trans. (LT loan extend to a bank) Gr 4 RCS

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 750,000; currency: DEM Gr 5 MOA

Counterpart: Gr 5 NAD

Banque d’Alsace, Reims

Austrian ID number: 756

Narrative 2 (bank’s foreign assets and liabilities)

For the compilation of the IIP, the Antwerp Bank NV, Brussels (ID number: 33897), has to report on its foreign assets and liabilities. In the first quarter 1992 the Antwerp Bank NV had USD 401,000 of claims on non-residents. These USD assets consist of a short-term claim of USD 325,000 on the Lahti Bank Oy, Helsinki, and foreign bonds, valued at USD 76,000, issued by the US government. Further, the Antwerp Bank NV had BEF 1,474,500 of liabilities to non-residents. These liabilities consist of sight deposits of BEF 667,000 held by the Hessen Bank AG, Frankfurt, and BEF 807,500 in long-term deposits held by the Electronic Instruments Ltd, Newcastle, United Kingdom.

Details EDIFACT segments

Reporting period (1^st quarter 1992) DTM

Reporting institution: Gr 2 NAD segment

Antwerp Bank, Brussels

ID number: 33897

FIRST OCCURRENCE Gr 3 RFF

Nature of transaction:

(ST claim on a bank), in code Gr 4 RCS

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 325,000; currency: USD Gr 5 MOA

Geographical detail: Finland (FI) Gr 5 LOC

SECOND OCCURRENCE Gr 3 RFF

Nature of transaction:

(foreign govern. bonds),in code Gr 4 RCS

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 76,000; currency: USD Gr 5 MOA

Geographical detail: United States (US) Gr 5 LOC

THIRD OCCURRENCE Gr 3 RFF

Nature of transaction:

(sight dep.of a bank), in code Gr 4 RCS

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 667,000; currency: BEF Gr 5 MOA

Geographical detail: Germany (DE) Gr 5 LOC

FOURTH OCCURRENCE Gr 3 RFF

Nature of transaction:

(LT dep.of a nonbank),in code Gr 4 RCS

Nature of trans. (ditto), in clear text Gr 4 FTX

Amount: 807,500; currency: BEF Gr 5 MOA

Geographical detail: United Kingdom (GB) Gr 5 LOC

 

GESMES/CB is a subset of the GESMES/ECOSER message, specially designed for statistical purposes. It is to be used by a BOP compiler to forward BOP and IIP data to international statistical organisations such as BIS, ECB, EUROSTAT, IMF and OECD, as well as to other BOP compilers.

BOP and IIP data are forwarded by BOP compilers to international statistical organisations to enable these organisations to make regional groupings of BOP and IIP and to analyse these data. Furthermore, BOP compilers exchange bilateral BOP and IIP data to improve these data. These data are the aggregated data of individual transactions. The aggregation is performed at several levels. The highest level is by period (month, quarter or year) and by reporting country. The next level is by nature of transaction, for instance, exports of goods. At the next level the data aggregated by the nature of transaction are specified by country of the non-resident engaged in the transaction (for instance, goods are exported by an enterprise to the United States) and by type of industrial activity of the residents engaged in the kind of transaction (for instance, goods are exported by agricultural enterprises).

Narrative

The Ufficio Italiano dei Cambi reports on a yearly basis BOP data to EUROSTAT. Part of the BOP data (questionnaire Y1) reported on 1998 relates to exports of goods to, for instance, France, Germany, the United Kingdom and Belgium valued at ITL 72 bln, 65 bln , 15 bln and 45 bln, respectively. Another part of the BOP data (questionnaire Y5-2) relates to direct investment in, for instance, an Italian oil company by a chemical industry based in the Netherlands valued at ITL 21 bln.

Details EDIFACT segments

Reporting institution: Gr 2 NAD

Ufficio Italiano dei Cambi

Rome, Italy

Questionnaire Y1 Gr 11 DSI

Gr 11 ARR

Reporting country (IT) 1^st item

Reporting period (199801-199812) 2^nd item

Nature of transaction (exp. of goods),in code 3^rd item (1^st line)

Type of flow (credit flow) 4^th item

Counterpart country (FR) 6^th item

Amount: 72 bln; 7^th item

Amount currency (ITL) 8^th item

Reporting country (IT) 1^st item

Reporting period (199801-199812) 2^nd item

Nature of transaction (exp. of goods),in code 3^rd item (2^nd line)

Type of flow (credit flow) 4^th item

Counterpart country (GE) 6^th item

Amount: 65 bln; 7^th item

Amount currency (ITL) 8^th item

Reporting country (IT) 1^st item

Reporting period (199801-199812) 2^nd item

Nature of transaction (exp. of goods),in code 3^rd item (3^rd line)

Type of flow (credit flow) 4^th item

Counterpart country (GB) 6^th item

Amount: 15 bln; 7^th item

Amount currency (ITL) 8^th item

Reporting country (IT) 1^st item

Reporting period (199801-199812) 2^nd item

Nature of transaction (exp. of goods),in code 3^rd item (4^th line)

Type of flow (credit flow) 4^th item

Counterpart country (BE) 6^th item

Amount: 45 bln; 7^th item

Another message:

Reporting institution: Gr 2 NAD

Ufficio Italiano dei Cambi

Rome, Italy

Questionnaire Y5-2 Gr 11 DSI

Gr 11 ARR

Reporting country (IT) 1^st item

Reporting period (199801-199812) 2^nd item

Nature of trans.

(dir.inv.in the report.econ.),in code: 3^rd item

Type of flow (credit flow) 4^th item

Resident industrial activity

(oil industry), in code 5^th item

Counterpart country (NL) 6^th item

Amount: 21 bln; 7^th item

Amount currency (ITL) 8^th item

 

To collect all BOP and IIP information for both BOP data statistical systems (the general collection and the survey-based system), the change requests for existing EDIFACT messages and the new EDI BOP messages have been designed in a flexible manner. The segments of these messages are in general conditional. Furthermore, the use of messages is fully optional. All messages stand on their own and could be used as such.

As for the possible use of these EDIFACT messages for collecting BOP and IIP data, annex 7 gives an overview by country.