III. International Transactions Reporting Systems
Author:
International Monetary Fund
Search for other papers by International Monetary Fund in
Current site
Google Scholar Close
Language:
English
Print Publication Date:
15 Mar 1995
Keywords:
BOOK; BOP compiler; BOP.; goods; enterprise; BOP transaction; unit of account; noncash transaction; bank client; bank assets; resident bank; Fiscal accounting and reporting; Currencies; Credit; Foreign banks
Download PDF (644.6 KB)

Abstract

63. An international transactions reporting system (that is, a system for reporting international transactions) measures: (1) individual BOP cash transactions that pass through domestic banks and through enterprise accounts with banks abroad, (2) noncash transactions, and (3) stock positions. Statistics are compiled from forms submitted to domestic banks and from forms submitted by enterprises. An international transactions reporting system (ITRS) can provide comprehensive and timely BOP statistics. Most international transactions reporting systems, which were formerly known as foreign exchange record systems, evolved as by-products of foreign exchange control systems. However, as foreign exchange restrictions were eased or lifted, many systems began to measure more than foreign exchange transactions; hence, a broader designation is necessary to describe them.

Introduction

63. An international transactions reporting system (that is, a system for reporting international transactions) measures: (1) individual BOP cash transactions that pass through domestic banks and through enterprise accounts with banks abroad, (2) noncash transactions, and (3) stock positions. Statistics are compiled from forms submitted to domestic banks and from forms submitted by enterprises. An international transactions reporting system (ITRS) can provide comprehensive and timely BOP statistics. Most international transactions reporting systems, which were formerly known as foreign exchange record systems, evolved as by-products of foreign exchange control systems. However, as foreign exchange restrictions were eased or lifted, many systems began to measure more than foreign exchange transactions; hence, a broader designation is necessary to describe them.

64. The comprehensiveness of these systems may vary. A closed ITRS accounts for all transactions and reconciles all transactions with corresponding changes in stock positions. In some closed systems, each form submitted by a client to a bank is matched with an entry in the bank’s foreign currency account. An open ITRS does not allow such complete accounting and reconciliation. Often, an open ITRS is a partial system because certain BOP transactions are not recorded. For example, the German system does not include exports of goods and short-term financial transactions, although it does provide for reconciliation of data on certain flows and stock positions.

65. The quality of these systems varies. Those that work well have clearly defined rules, a sound legal basis, well-designed collection forms and procedures, cooperative reporters, adequate resources, and well-trained staff.

Model of a Simple ITRS

Scope of an ITRS

66. A model of a simple ITRS is used to illustrate operation of this type of collection system. The model is based on the assumptions that residents (other than banks with foreign exchange licenses) cannot hold foreign exchange accounts with resident banks or any accounts with nonresident banks and that nonresidents cannot hold accounts with domestic banks. These assumptions, which would be valid in a country with tight foreign exchange controls, are dispensed with later in the chapter.

67. Under these assumptions, four types of foreign exchange transactions may be recorded:

  • (1) A bank client buys foreign exchange from a domestic bank to make a payment to a nonresident. The obverse is that a bank client sells foreign exchange, which has been received as a payment from a nonresident, to a domestic bank.

  • (2) To travel abroad, a resident individual acquires foreign currency travelers’ checks from a domestic bank. The obverse is that a bank buys foreign (or domestic) currency travelers’ checks from a nonresident traveler who is traveling in the domestic economy.

  • (3) A resident bank undertakes a foreign exchange transaction with a correspondent nonresident bank abroad. This transaction may be undertaken to exchange foreign exchange assets denominated in one currency for those denominated in another or to acquire (or sell) goods, services, other financial assets, etc.

  • (4) A resident bank undertakes a foreign exchange transaction with another resident bank. This transaction may be undertaken to settle balances in various currencies or to sell (or buy) foreign exchange to (from) the central bank.

68. In case (1), when a bank client buys foreign exchange from a domestic bank, the client can only use these funds to make a payment to a nonresident. This limitation follows from the assumption that the client is not permitted to hold foreign exchange. At the same time, the bank must reduce its holdings of foreign exchange.13

Under a closed ITRS, both the sale of foreign exchange to the client and the corresponding reduction in the bank’s foreign exchange position should be recorded. The purpose of the resident client’s acquisition of funds is recorded in an ITRS. For example, if a resident acquires 100 units of foreign exchange to purchase goods from abroad, the following entries would be recorded in a closed ITRS:

article image

69. On the other hand, if a client receives 120 units of foreign exchange funds from selling goods abroad, the appropriate entries would be:

article image

70. In case (2), a transaction could arise as a result of a domestic bank either acquiring travelers’ checks from a nonresident traveler or from selling travelers’ checks to a resident traveler. In such instances, these transactions may be recorded either at the time of the purchase (or sale) of the travelers’ checks from (to) the individual traveler or at the time the domestic bank settles with the nonresident correspondent bank. For purposes of exposition, it is assumed that such transactions are recorded at the time of settlement with the correspondent bank. For example, if a domestic bank purchases 60 units of travelers’ checks (which the bank had originally issued to residents) from a correspondent nonresident bank and sells 50 units of travelers’ checks (issued by a nonresident bank and purchased from nonresident travelers) to the correspondent nonresident bank, the appropriate entries are:

article image

71. An example for case (3) would be a settlement transaction in which a domestic bank sells 20 units of currency y for 24 units of currency z. (One unit of currency y equals 1.2 units of currency z.) The appropriate entries would be:

article image

For purposes of completeness and reconciliation, settlement transactions should be recorded in the ITRS. In theory, such transactions should be offsetting on consolidation.

72. Case (3) also covers transactions other than those of a settlement nature. For example, a domestic bank may acquire, at a cost of 5 units, the services of a nonresident accountant; receive a commission of 6 units on the sale of travelers’ checks issued on behalf of a nonresident bank; and make a repayment and pay interest of 37 units and 8 units, respectively, on a loan. Payments for all of these items would be made through the domestic bank’s foreign exchange account with a nonresident bank. The following entries should be recorded:

article image

73. Entries for case (4) are similar to the entries for settlement transactions recorded in case (3). For example, a domestic bank (bank A) sells 25 units of foreign exchange to another domestic bank (bank B) and 33 units of foreign exchange to the central bank. Settlement is undertaken in domestic currency. The following entries should be recorded in the ITRS:

article image

74. Settlements involving domestic banks and settlements involving nonresident banks should be separately identified in an ITRS. For the former, the corresponding bank should be identified so that these entries (particularly those for large transactions) can be matched by the ITRS compiler. For settlements involving nonresident banks, the currency used in the other part of the transaction should be identified so that the two sides of the transaction can be matched.

Data Items Collected

75. The form completed by the bank client14 may include the reference number of the transaction, the reference period, the identity of the transactor, the identity of the bank accepting the form, the direction of the transaction (i.e., the sale or purchase of foreign exchange), the currency used in the transaction, the value of the transaction (either in terms of the currency used, the unit of account, or both), classification of the purpose of the transaction, and the country of the nonresident party.15 In addition, banks should record corresponding details of their own transactions—for purposes of matching their transactions with those of clients—and details of their foreign currency (and other external asset and liability) positions—for purposes of providing IIP data and for reconciling transactions and stock positions.

Classification of Transactions

76. To compile a BOP statement, it is necessary to ensure that the classification of transactions used in the ITRS conforms, as closely as possible, to the classification required for the BOP statement.16 In the examples in paragraph 67, each transaction was recorded either as a recognizable BOP classification item or as a settlement item. While settlement items are not to be recorded in the BOP statement (in theory they should offset and, on a net basis, cancel each other), settlement items are required in the system to ensure that all transactions are accounted for.17

77. The classifying of a particular transaction to the appropriate BOP category should be undertaken by someone who has extensive knowledge of commercial practice and BOP classification requirements. This issue is addressed in chapter 18.

Aggregating the Results

78. Using the examples from paragraphs 68-73, table 3.1 on page 18 illustrates aggregation of the results of an ITRS collection. Financial account transactions and settlement entries are shown on a net basis. Initially, results should be compiled by bank and by currency. In aggregation of results, it is important that all transactions be recorded. If all procedures are adhered to, total credits should equal total debits, and results should also balance by bank and by currency.

Table 3.1.

Summary of ITRS Transactions from Previous Examples

article image

79. The next step is to ensure that all settlement entries within the system are offsetting. The results shown in table 3.2 are obtained by summarizing settlement entries and omitting offsetting credit and debit entries.

Table 3.2.

Summary of Settlement Transactions Shown in Table 3.1

article image
Note: In the example, the conversion ratio of y to z is 1 to 1.2; therefore, the two entries are offsetting.

80. Conversion of all currencies to the common unit of account demonstrates that settlements are totally offsetting; therefore, the system is fully balanced. In practice, systems may not fully balance; minor imbalances are acceptable. Major imbalances, which indicate errors in data, should be investigated and resolved.

81. The next step in the aggregation process is to reconcile flows and stock positions. Reconciliation can be achieved by comparing opening and closing foreign exchange positions (which are arrived at independently) with total credit and debit entries (except for entries measuring changes in banks’ foreign exchange positions). Table 3.3 on page 19 shows such a reconciliation. In the table, the opening stock position plus credit entries (which are offset entries to increases in banks’ foreign exchange accounts) less the debit entries (which are offsets to reductions in banks’ foreign exchange accounts) should equal the banks’ closing foreign exchange positions. Any discrepancy discovered in this reconciliation process would be shown in the other changes column. In practice, the BOP compiler should obtain results that approximate a full reconciliation; any major discrepancy may indicate errors in data.

Table 3.3.

Reconciliation of Opening and Closing Positions with Transactions

article image

The total of y and z stock positions and transactions is obtained by converting amounts expressed in currency z to currency y. For simplicity, it is assumed that both positions and transactions are converted by using the ratio 1.2 z to 1 y.

When die various entries (shown in table 3.1) for changes in banks1 foreign exchange assets are summed, the result is a credit entry of 54 for currency y and a debit entry of 24 for currency z; the entry for currency z, when expressed in currency y, is a debit entry of 20. This gives a net credit entry of 34 for bank’s foreign exchange assets. Credit and debit entries in the reconciliation would balance with the addition of the credit entry of 34 for the change in banks’ foreign exchange assets.

82. Table 3.3 shows that the sum of credit entries less the sum of debit entries accounts for the changes in foreign exchange stock positions of the banks shown in table 3.1; therefore, a full reconciliation has been achieved.

Currency Conversion

83. The BPM recommends that transactions expressed in one currency be converted, by use of the midpoint rate applicable to each transaction, to the common unit of account in which the BOP is compiled. Corresponding stock data should be converted by use of a midpoint market rate applicable to the date on which the stock position is measured.

84. Systems in which the value of each transaction is recorded in the unit of account, rather than in the transaction currency, are consistent with recommendations of the BPM to the extent that prevailing market exchange rates are used by reporters for the conversion. In these systems, the matching of settlement transactions and the reconciliation of stocks and flows data are then undertaken in the unit of account. However, it is sometimes difficult for the compiler to discern whether the non-transaction changes in stocks, which are derived as residuals, are due to errors in the recording of transactions or to exchange rate fluctuations.

85. In systems in which the values of transactions are recorded in the currencies in which they are denominated, data are aggregated by currency (as shown in the previous part of this chapter) and reconciliations are performed in each currency. The advantage of this approach is that changes in stocks should more closely match transactions because exchange rate fluctuations are not relevant. Exchange rates prevailing at the time of the transaction should be used for matching settlement transactions involving different currencies. However, for practical reasons, period average exchange rates are often used for this process, and the balance on settlement is assumed to represent part of the transactions in foreign currency assets. After reconciling and matching processes are completed, data are converted-typically by use of period average exchange rates-to the common unit of account and aggregated. The disadvantage of this method is lack of consistency with recommendations in the BPM, which requires the use of actual, not average, exchange rates. Apart from offsetting errors that this approach introduces into the BOP statement, it could also cause problems in the national accounts when the values of items, such as imports, differ from those for related series, such as investments.18

86. In practice, use of the second methodology may, particularly when exchange rates are not volatile, yield results similar to those that would be produced if the BPM methodology were used. Unfortunately, there is little information on the statistical impact of using different conversion procedures. One possible solution is to collect (by using the midpoint rate applicable to the transactions) the value of each transaction in the unit of account and in the currency used in the transaction.19

Time of Recording

87. Up to this point, it has been assumed that both sides of a transaction would be recorded in an ITRS at the same time. Simultaneous recording should be achieved by individual bank reporters within a closed system because a uniform time of recording can be maintained by matching entries that pass through a bank’s nostro and vostro accounts against collection forms completed by transactors (or records thereof).20 A record should be created for any nostro and vostro account entries for which no corresponding collection forms exist. Similarly, collection forms for which no nostro or vostro account entries can be identified should be investigated and canceled if underlying transactions are canceled or otherwise not completed.

88. However, all banks in the system will not keep books in the same manner unless required to do so by law. Different banks may have different ideas of what should be included in foreign exchange assets. Ideally, banks should account for foreign currency, foreign exchange bank balances, bills and notes of other banks sent for collection or held for investment purposes, and other foreign securities and loans. Also, banks should account for any foreign liabilities.21 Banks may choose to record transactions in some of these assets and liabilities when claims are created, when claims are sent for collection, or when amounts are recorded in nostro accounts.22

89. Even if all banks include all the transactions covered by the assets and liabilities mentioned previously and choose similar reporting procedures, there may still be timing lags; thus, two domestic banks involved in a foreign exchange settlement may not record the settlement in the same accounting period. This circumstance could easily give rise to a discrepancy in the total settlement item; hence, the compiler should check each large settlement transaction between domestic banks and ensure that both sides of the transaction have been recorded in the same period. If both parties have not recorded the transaction in the same period, it is necessary to have the reporting banks correct their data or, if different accounting practices make that inappropriate, the compiler should make an adjustment.

90. The foregoing discussion demonstrates the necessity for the compiler to investigate and obtain an understanding of the accounting practices used by banks and to determine the impact of these accounting procedures on both the scope and timing of ITRS statistics.

Valuation, Bundling, and Netting Practices

91. An ITRS may not achieve uniform valuations. For example, goods may be recorded, depending on the contract price in individual transactions, on an f.o.b., c.i.f, or some other basis. The BPM requires the compiler to record goods on a uniform, namely the f.o.b., basis. Therefore, the compiler may have to make certain valuation adjustments to ITRS statistics to compile a BOP statement.

92. Bundling of transactions occurs when several transactions relating to more than one classification category are covered by a single payment. For example, a payment on a loan may include the loan repayment, an interest payment, and some fees for financial services. It is necessary for transactors to report the separate components.

93. Another example of bundling is the recording of transactions on a net, rather than a gross, basis. Some foreign exchange payments may cover a number of offsetting gross credit and debit transactions; this may often be the case with transactions undertaken by transportation, travel, and finance enterprises and enterprises in a direct investment relationship. Therefore, it may be necessary to collect additional information in respect of certain types of transactions or from certain types of enterprises, or it may be necessary to split certain transactions into component parts.23

Threshold Practices

94. In many international transactions reporting systems, thresholds are used so that transactions of less than certain amounts need not be reported. Compilers have generally found large numbers of transactions that, in aggregate, account for small values. The use of thresholds prevents undue reporting burdens and processing costs. However, while it may be unnecessary to report small transactions individually, an aggregate record of small transactions should be kept to obtain overall aggregate results and to assist in the process of reconciliation. For classification purposes, it may be necessary to have some information on types of transactions that fall below the threshold. This information may be gathered from periodic sample surveys (which could be small, ad-hoc surveys carried out via special arrangement with one or more commercial banks) or from an analysis, which could be undertaken before thresholds were raised, of small transactions. The compiler may feel more comfortable about using higher thresholds if information on the size and classification of small transactions is available. It is important that judgement be applied in adopting thresholds so that overall data quality data remains acceptable.

Modifying the Model of the Simple ITRS

95. The model of a simple ITRS is suitable for situations in which (1) residents of a country cannot hold foreign currency accounts with domestic banks or accounts with nonresident banks; (2) nonresidents cannot hold accounts with the domestic banks; and (3) residents cannot have other external claims or liabilities, such as trade credit or loans. However, as foreign exchange regulations are relaxed or abolished, these assumptions often cease to apply. Therefore, compilers in many countries have modified their systems so that:

  • (1) residents who have foreign currency accounts at domestic banks or accounts at nonresident banks report details of account transactions and balances;

  • (2) residents report details of domestic currency transactions involving nonresident bank accounts at domestic banks;

  • (3) transactions performed through nonresident bank accounts at resident banks are monitored, although the nonresident entity has no obligation to report details of individual transactions. (When the counterpart is a resident entity, details of the transaction—as noted in item 2—would be reported by the resident entity.);

  • (4) enterprises report details of their noncash transactions, such as the granting of trade credit or loans, with nonresidents and the corresponding stock positions.

96. One important conceptual issue for an ITRS is the inclusion or exclusion of offshore banking units established in a country. Such units are usually permitted to accept deposits from, and make loans to, nonresidents only. Transactions between these institutions and nonresidents need not be included in an ITRS. However, if offshore banks are regarded as residents of the compiling country, the offshore banks should report details of aggregate transactions and corresponding stock positions with nonresident clients. Offshore banking units should be treated—for purposes of compiling national accounts, the BOP, and IIP statistics—as residents of the countries in which they are located. If resident enterprises have accounts with offshore banks, the accounts may be used to settle transactions with nonresidents; these transactions should be measured in an ITRS. It is important for the compiler to ensure that reporting arrangements cover all BOP requirements and that omission or duplication of data is avoided.

Measurement of Noncash Transactions

97. A closed ITRS can provide a complete statement of transactions that take place between residents and nonresidents and involve cash payments. However, the BOP analyst is also concerned with the measurement of transactions that occur between residents and nonresidents and do not involve cash payments. The BOP compiler should ensure that the noncash transactions presented in the following discussion are collected in the ITRS or added to basic ITRS statistics when BOP and IIP statements are prepared.

98. Exports and imports financed by loans may not involve cash payments. For example, an exporter may arrange for a financial institution to provide financing to a nonresident importer, and the exporter may be paid in domestic currency by the lender. Consequently, there may be no entry in a bank nostro (or vostro) account until the loan is repaid, and then the transaction may be recorded (correctly) as a loan repayment rather than as an export. Similarly, an importer may borrow funds to purchase goods abroad. In most circumstances, the borrowed funds would pass directly from the financier to the nonresident exporter and, therefore, no cash payment would be involved. If the ITRS does not capture noncash transactions of this nature, lenders and borrowers should be identified and the basic cash data should be supplemented-as shown in the following example. In the example, export financing has been provided by residents for exports valued at 76 units, and import financing valued at 89 has been obtained from nonresidents.

article image

99. The value of goods for which prepayment was made or the value of goods sold on short-term credit is recorded in many an ITRS when payment is made. Therefore, the period in which payment is recorded may be different from that in which change of ownership of the goods occurs. It is possible to record goods and associated finance flows if supplementary data are collected to indicate the period in which the goods changed ownership or were shipped. For example, in a specific period, an ITRS may be used to identify export receipts of 240 units, 20 of which represent prepayments for goods to be delivered in a future period and 21 of which represent goods delivered in a previous period. Supplementary sources may be used to identify prepaid delivery of 23 units of goods and delivery of 27 units of goods for which payment will be made at a future date. The results would be:

article image

100. Certain goods and services that are provided under foreign aid programs (and for which payment is made by the donor to the supplier) would not be recorded as cash transactions in an ITRS. The compiler should identify these transactions and record them in the BOP. In the following example, an aid donor provides food aid to another economy and pays a food producer in the home country. The resulting additional BOP entries are:

article image

101. A similar situation exists when certain goods and services are provided, without any corresponding cash flow, by a direct investor to a direct investment enterprise. In such circumstances, book entries may show additional share capital issued to the direct investor or a loan made by the direct investor to the direct investment enterprise. These transactions would not be recorded as cash transactions in an ITRS. The compiler should identify these transactions and record them in the BOP as:

article image

102. Examples of other noncash transactions include goods for processing that cross the boundary of the economy, debt rescheduling, arrears, debt cancellation (with the concurrence of both parties), dividend to equity conversion, interest and debt to equity conversion, etc. The compiler should identify these transactions to compile a BOP statement on an accrual basis.

103. Finally, reinvested earnings (income) on direct investment (and the offset in the financial account) would not be measured in an ITRS without a special arrangement. Therefore, data on reinvested earnings should be collected from direct investment or direct investor enterprises.

Preparation of a BOP Statement

104. While most compilers prefer to use ITS for compiling the goods item in the BOP, compilers in some countries use international transactions reporting systems that may have to be adjusted in a number of ways.

105. In respect of coverage, goods financed via loans, goods that form part of foreign aid programs, migrants’ effects, and goods traded between direct investment enterprises are examples of goods transactions that may not be captured in an ITRS and should be identified and included. Any adjustment made to the goods item in an ITRS represents one side of the transaction, and a corresponding adjustment should be made to the other item in the account.

106. Goods that do not undergo a change of ownership but enter or leave an economy for processing may also require identification and appropriate recording.24

107. Goods regarded as merchanting transactions should be treated in accordance with recommendations of the BPM.25

108. When a change of ownership for goods and payment for these goods are recorded in different periods, a timing adjustment may be required. Such adjustments would be necessary for goods transactions involving prepayments or other trade credits. Corresponding adjustments would be required in the financial account to record transactions arising from the creation and extinguishment of these short-term assets and liabilities.

109. In respect of valuation, it is important to identify the basis on which goods are imported or exported. For imports and exports recorded on an f.o.b. basis, no adjustment is necessary. For goods traded on some other basis, adjustments are necessary. For example, for goods traded on a c.i.f. basis, the insurance and freight elements should be identified and included in transportation and insurance services, respectively, (rather than in goods).26

110. In respect of transportation and travel, it is usually necessary to supplement ITRS data on transport and travel enterprises to ensure that sufficient data are collected and that data are correctly classified. A discussion of the type of data that may be collected from these enterprises is included in chapters 4 (enterprises involved in travel) and 5 (enterprises involved in transportation). The ITRS measurement of travel may have to be augmented to take account of transactions involving foreign currency notes and coins that do not pass through the domestic banking system.

111. Comprehensive statistics on other services can be obtained from an ITRS. These statistics reflect the times at which the services are paid for rather than rendered. Most compilers who use international transactions reporting systems consider payments data to be appropriate approximations for times when services were rendered. However, it would be desirable for compilers to obtain information on these relationships to ensure that this view is reasonable.

112. Income should be recorded when it is accrued rather than when it is actually received or paid. Most compilers who use international transactions reporting systems view payments data as appropriate approximations, in most cases, for times when income is due. However, compilers should adjust ITRS data for reinvested earnings on direct investment and for significant cases in which interest income is accrued and not paid (for example, deep discounted and zero coupon bonds, discounted bills, and interest in arrears). In these cases, the compiler should keep a special tabulation, or collect supplementary information, to make the necessary adjustments.27 Further, it is important to ensure that income and financial account transactions are clearly separated in ITRS statistics. For example, in some systems, loan repayments and interest payments may are reported as a single item by transactors. This type of reporting is likely to occur when financial leases are involved and, in these instances, the compiler should distinguish between income and repayment elements.28

113. Transfers recorded in ITRS statistics are usually reported at times of payment. Most compilers who use international transactions reporting systems consider payments data to be reasonable approximations for times when changes of ownership occur in underlying resources. In addition, it is necessary to record any transfers in kind (particularly those that form part of foreign development assistance and military aid) that are not encompassed in ITRS statistics.

114. Financial account transactions measured by ITRS statistics tend to coincide with the BPM requirement on time of recording of financial flows, namely, when investment takes place and when drawings and repayments on loans occur. The compiler may have to supplement ITRS statistics with data on financial transactions that may not be measured by an ITRS (for example, loans involving trade finance, the incurrance of arrears, debt rescheduling, debt cancellation, and debt to equity conversions). Also, adjustments that are made to other items in ITRS statistics and that involve financial items (e.g., goods involving trade credit and prepayments, interest accrued but not paid) would have offsets recorded in the financial account.

115. Ideally, reserve asset transactions would be included in ITRS statistics.

116. In closed systems there are, in theory, no net errors and omissions items. The absence of these items, does not mean that there are no gross errors or omissions but that, in a closed system, accounts should balance.

A Model ITRS

117. This chapter has described the key features of an ITRS and the general steps involved in compiling BOP statistics from ITRS statistics. For additional information on the development of an ITRS, see chapter 18 wherein the design of a collection and processing system is outlined. Model ITRS collection forms appear in appendix 2. The forms include descriptions of various features that an ITRS may contain. An outline of the forms is presented in chapter 19.

118. The model ITRS outlined in chapter 18 is a closed system. The model collection forms capture:

  • single transactions reported to the banking system (forms 3P and 3C);

  • transactions passing through enterprise bank accounts at nonresident banks and through foreign currency accounts at domestic banks, noncash transactions, and external asset and liability positions (form 5);

  • banks’ own transactions and stock positions and data reconciling stock positions and flows (form 4).

Another form (form 3M) demonstrates how an ITRS could be used to capture data on goods transactions. Form 13 on security transactions of financial intermediaries may also be a part of the suite of ITRS forms. However, these forms do not comprise the universe of forms required for an ITRS. For example, a supplementary form must be developed to measure reinvested earnings on direct investment; this form could be modeled on form 12, parts G and H. In addition, many special forms (which could be developed from other model forms) may have to be developed for goods for processing (form 6), transportation (forms 7 and 8), travel (form 9), insurance (form 10), compensation of employees (form 11), and foreign embassies and international institutions (form 14). These forms are discussed in subsequent chapters of the Guide.

119. It is assumed that the model ITRS would use thresholds supplemented by sample surveys of small transactions.

120. Classification codes for transactions (and stock positions) that appear on model forms are listed on form 3C and are consistent with those of the BPM.29 Infrequently used codes are not shown. (In some countries, individual codes are added to the classification framework after compilers consult with particular enterprises engaged in specialized activities and with the central bank in respect of government activities.) Excluding specialized codes on the general forms avoids the problem of overburdening respondents with instructions and classifications.

Electronic Reporting

Introduction

121. ITRS data have typically been reported on paper, but electronic transmissions are increasingly being used. Until the 1990s, standards for electronic transmissions remained national. However, the movement towards a global marketplace has required an international standard for electronic transfer, from computer to computer, of commercial or administrative transactions. Such a standard, known as Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), has been developed under the auspices of the United Nations. The EDIFACT standard is also used in preparing electronic communications for BOP purposes.

EDIFACT Communications for BOP Purposes

122. EDIFACT communications can be used, as appropriate, to collect BOP data for an ITRS or ES. For an ITRS, the communications can contain data on separate transactions reported, either via a commercial bank or directly to the BOP compiler, by nonbank transactors. The communications can also contain data on bank transactions reported to the BOP compiler, as well as data reported to international statistical organizations by the BOP compiler. For enterprise surveys, the communications could contain a combination of balance sheet and aggregated transactions data.

123. The type of EDIFACT communication depends on the parties exchanging data. The following data flows can be distinguished:

  • from customers to banks;

  • from banks to the BOP compiler;

  • from enterprises to the BOP compiler;

  • from BOP compiler to international organizations and vice versa and between BOP compilers.

124. For data flows from customers to banks, existing (but slightly modified) EDIFACT financial payment messages can be used. For other flows, new EDIFACT messages have been developed.

125. EDIFACT messages have been developed by using internationally standardized building blocks (segments). An example of such a segment is the NAD segment, which contains information on name, address, and domicile. In EDIFACT syntax, segments can be mandatory or conditional. In new EDIFACT messages, the majority of the segments are made conditional (optional) to accommodate different national requirements. If BOP compilers wish to ensure receipt of particular information, conditional segments of the message could be made mandatory via national requirements.

Specific Messages

126. The diagram in illustration 3.1 shows EDIFACT messages that could be used for collecting BOP data.

Illustration 3.1
Illustration 3.1

BOP Reporting and EDIFACT Messages

127. The diagram shows the following data flows:

  • PAYORD—a payment to be reported via a commercial bank to the BOP compiler

  • BOPINF—a receipt to be reported via a commercial bank to the BOP compiler

  • BOPCUS—individual payments/receipts to be reported to the BOP compiler by a commercial bank

  • BOPDIR—transactions in accounts held with nonresidents, foreign positions, and survey results to be reported directly to the BOP compiler

  • BOPBNK—banks’ transactions and foreign positions

  • BOPSTA—data to be forwarded by a BOP compiler to international statistical organizations and to other BOP compilers

  • FINPAY—a message concerning a payment involving banks in two countries; possibly combined with BOP data in the future.

128. There is also a CUSDEC message, which could be used for collecting international trade statistics.

Benefits

129. Use of the UN EDIFACT standard is steadily expanding on a worldwide basis. As more and more business systems conform to EDIFACT, the process for using these messages to report information to authorities will become more efficient. Ready access to electronic data reduces costs for enterprises and for banks acting as intermediaries in the data collection process. These cost savings stem from the “automatic” nature of data provision. Once reporters have programmed their systems to send relevant data to BOP compilers, there is no necessity for subsequent reporting unless changes occur in reporting requirements or in reporters’ systems. Benefits to BOP compilers include more timely and more accurate data.

Within Same Series

Other IMF Content

Other Publishers Content

  • Collapse
  • Expand
Cover Balance of Payments Compilation Guide
Balance of Payments Compilation Guide
ISBN:
9781557754707
Publication Date:
15 Mar 1995
Publisher:
International Monetary Fund
DOI:
https://doi.org/10.5089/9781557754707.071
Pages:
396
Illustration 3.1

BOP Reporting and EDIFACT Messages