Chapter

4. International Transactions Reporting System

Author(s):
Eduardo Valdivia-Velarde, and Tamara Razin
Published Date:
December 2014
Share
  • ShareShare
Show Summary Details

4.1 The international transactions reporting system (ITRS) 1 is part of the broader institutional data collection framework of many economies. It differs from economy to economy, drawing from economies’ legal framework, accounting systems, and foreign exchange regulations; however, virtually all such systems have certain features in common. Most ITRS (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 were extended beyond their original purpose of measuring foreign exchange transactions; hence, a broader designation is necessary to describe them. This chapter outlines features of an ITRS and also discusses the use of an ITRS in compiling balance of payments and IIP statistics.

4.2 As a general rule, an ITRS is a data collection system that obtains data from banks and companies at the level of individual transactions. The most comprehensive “traditional” ITRS measures: (1) cash transactions with nonresidents that pass through domestic banks; (2) cash transactions that pass through enterprise accounts with banks abroad; (3) transactions on intercompany accounts with nonresident companies; (4) positions; and (5) noncash transactions. Statistics are compiled from forms submitted to/by domestic banks and from forms submitted by companies.

ITRS Reporters

4.3 An ITRS typically collects data from reporters in the banking sector including the central bank, and selected companies called direct reporters that report directly to the balance of payments compiling institution.

4.4 The banking sector is central to the ITRS. Banks report all operations that are carried out between residents and nonresidents through their books on their own account and on the account of their clients. In economies with foreign exchange restrictions that do not allow residents to hold foreign exchange accounts with resident banks, clients’ foreign exchange purchases and sales transactions with nonresidents can be captured. Also, nonresidents’ accounts in domestic currency with resident banks should be monitored, if nonresidents are allowed to hold such accounts.

4.5 In economies where residents can hold foreign exchange accounts, the ITRS is focused on collecting transactions going through banks’ correspondent accounts. Such accounts include (1) nostro accounts—correspondent accounts of resident banks with banks abroad2 and (2) vostro accounts that are nonresident banks’ accounts with resident banks.3 In addition, the ITRS includes resident companies’ accounts with nonresident banks and nonresidents’ accounts (other than banks) with resident banks. Regarding the banks’ own transactions, banks should account for foreign currency (banknotes) accounts, their correspondent and deposit accounts with nonresident banks, nonresident banks accounts in domestic banks, and other security and loan accounts that involve transactions with nonresidents.

4.6 Other ITRS reporters are companies called direct reporters. Two types of direct reporters could be identified:

  • (1) Full direct reporters (FDR) are companies with a high degree of cross border transactions that conduct their transactions through accounts with domestic banks and, in some cases, through accounts with banks abroad and intercompany accounts. FDRs report to balance of payments compilers all transactions and positions with nonresidents conducted through all mentioned accounts. In a closed system, domestic banks will also report FDR transactions conducted through domestic accounts; however, they will classify these transactions as neutral, to avoid duplication.

  • (2) Partial direct reporters (PDR) are companies that have accounts with nonresident banks and are not FDRs. PDRs report directly to the compiler only transactions through accounts abroad.

Comprehensiveness of ITRS

4.7 The comprehensiveness of ITRS may vary, and it in general determines to which extent the compilation of the balance of payments depends on other sources. A fully comprehensive ITRS must include banks and direct reporters’ transactions, which are reconciled with resident banks’ foreign currency positions or with external assets and liabilities positions of direct reporters. In terms of comprehensiveness, the ITRS can be closed, partial (semiclosed), or open. A closed ITRS accounts for all transactions and reconciles all transactions going through targeted accounts with corresponding changes in positions. An open ITRS does not allow such complete accounting and reconciliation. In a partial ITRS, certain balance of payments transactions are not recorded or the system allows for reconciliation of flows and positions only for some accounts. For example, the system may not include transactions involving exports and imports of goods, although it may provide for reconciliation of data on certain flows and positions.

Data Items Collected

4.8 The report form is completed by the bank client and/or by the bank staff based on information/ documents provided by the client. The report form includes the reference number of the transaction, the reference period, the identity of the transactor, the identity of the bank accepting the form, the currency used in the transaction, the value of the transaction (either in terms of the currency used, the unit of account, or both), the classification and description of the purpose of the transaction (i.e., payment/receipts for import/export of goods), and the economy of the nonresident party. Banks record also their own transactions and details of their foreign currency (and other external asset and liability) positions for purposes of providing IIP data and for reconciling transactions and positions.

4.9Appendix 8 presents model ITRS collection forms, as well as their outline. The model collection forms are designed for a closed ITRS and include the following:

  • Form 3-1 ITRS-Payments and Receipts—Single transactions reported to the banking system by banks’ clients or by banks on behalf of their clients

  • Form 3-2 ITRS-Imports and Exports—Demonstrates how an ITRS could be used to capture data on goods transactions; although it is not recommended to compile goods statistics based on ITRS due to limitations described in Chapter 11

  • Form 3-3 ITRS-Companies—For FDRs it covers transactions passing through company foreign currency accounts at domestic banks, bank accounts with nonresident banks, noncash transactions, and external asset and liability positions. For PDRs, it includes transactions passing through company bank accounts with nonresident banks, including positions

  • Forms 3-4 ITRS-Banks and 3-5 ITRS-Banks’ Record of Transactions—Includes the reporting of banks’ own transactions and positions and data reconciling positions and flows.

4.10 The presented forms could be used for collecting data with or without a threshold. If a threshold is established, it is beneficial if transactions below the threshold level, if material, are reported in an aggregated amount classified using the appropriate code.

4.11 A list of model classification codes for transactions (and positions) is presented in the Annex to Forms 3-3–3-5 for ITRS-Classifications. In the list, infrequently used codes are not shown. (In some economies, individual codes are added to the classification framework after compilers consult with particular companies engaged in specialized activities and with the central bank in respect of government activities and of reserve assets transactions.) Excluding specialized codes on the general forms avoids the problem of overburdening respondents with instructions and classifications. The list includes codes for selected neutral transactions such as transfer of funds between accounts or transactions of FDR included in the banks report. These transactions should be reported to allow for reconciliation of flows and positions, although they are not included in balance of payments statement.

Reporting Threshold

4.12 In many ITRS, thresholds are established for reporting transactions. Large numbers of transactions are of small value and, in aggregate, also may account for insignificant values. The use of thresholds prevents undue reporting burdens and processing costs. The thresholds can be simplification or exemption. With an exemption threshold, the small value transactions that fall below the predetermined amount are not reported. The simplification threshold requires reporting of small value transactions in an aggregate amount or without being classified by the purpose of transaction. The collection of small value transactions allows for the reconciliation of flows and positions and also assures a full coverage of ITRS in aggregate transactions in balance of payments statistics. It is important that judgment be applied in adopting thresholds so that overall data quality remains acceptable.

4.13 When a simplification threshold is applied, the collected information on transactions falling below the threshold should be attributed to the balance of payments accounts. Different approaches could be applied. Particularly, the information on purpose of small value transactions may be collected from periodic sample surveys (which could be small, ad hoc surveys carried out via special arrangement with one or more commercial banks). The examination of survey results will help in determining appropriate classifications for transactions so that data on transactions occurring above the threshold may be supplemented with data on small transactions that are appropriately classified. Also, information on data below the threshold can be gathered from an analysis of small transactions before the threshold is raised. If one of these methods is utilized, relatively high thresholds can be used without jeopardizing quality.

4.14 In some cases, when the small value transactions are collected but without their classification by purpose, the compiler can attribute them to balance of payments accounts by analyzing the description of transaction purpose or the information on resident transactor, if such information is available. In some cases, the compiler could classify only transactions that prevail by purpose (e. g., transfers by individuals that could be attributed to remittances measures) and the remaining small value transactions could be attributed to accounts applying the same approach as described in the previous paragraph.

Classification of Transactions

4.15 To compile a balance of payments 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 balance of payments statement. The coding system should be intuitive and could be customized for different reporters. For example, the list of codes for banks and PDRs may include only cash transactions, while the list of codes for FDRs could include also codes for noncash transactions (examples of noncash transactions are provided in paragraphs 4.43–4.44). This would reduce the number of codes and lessen the reporting burden.

4.16 The list of codes should include codes for all balance of payments components; however, transactions that occur rarely (e.g., some types of services) could be classified as “other n.i.e.” Special codes (also called neutral codes) should be identified for transactions that are not included in balance of payments statement but are recorded in the ITRS to improve the efficiency of the system and for cross-checking purposes. For example, neutral codes should be included for FDR’s transactions reported by the bank or for cross border transactions carried out by one resident bank on behalf of another resident bank, if the former is also an ITRS reporter. A model list of codes of transaction purposes is presented in the Annex to Forms 3-3–3-5 for ITRS-Classifications in Appendix 8; it addresses main balance of payments items. The list of codes should be accompanied by a detailed description/ explanation of transactions classified under each code.

4.17 An important and often difficult part of data collection is the classification of transactions. It can be executed by the transactor (bank’s client) while ordering a payment, by the bank staff based on the information from the client, or by balance of payments compilers. The reporter should provide information that is sufficient to ensure correct coding and coding cross-checks. A system in which the reporter both describes and codes the transaction usually produces the best results, especially if the codes are checked by the compiler. It is important that the compiler review the codes for accuracy, because accurate balance of payments classifications require the input of specialists with knowledge both of commercial practices and balance of payments classifications.

Currency Conversion

4.18 The balance of payments methodology generally recommends that transactions expressed in one currency be converted into domestic currency or in other currency in which the balance of payments is compiled (unit of account) by using the daily average midpoint exchange rate for transactions aggregated for a day. If data are collected in currency of transaction but aggregated for a longer period (e.g., week, month) the average midpoint exchange rate for the given period is used for converting into the unit of account. Corresponding position data should be converted by use of a midpoint market rate applicable to the date on which the position is measured.

4.19 Systems that record the value of each transaction in the unit of account, rather than in the transaction currency, are consistent with recommendations of the balance of payments methodology, assuming that prevailing market exchange rates are used by reporters for the conversion. In these systems, the reconciliation of settlement transactions to changes in positions must be undertaken in the unit of account. In this circumstance, it may be difficult for the compiler to discern whether the nontransaction changes in positions, which are derived as residuals, are due to errors in the recording of transactions and positions, or to use of inexact exchange rates.

4.20 In systems in which the values of transactions are recorded in the currencies in which they are denominated, data are aggregated by currency, and reconciliations are performed in each individual currency. The advantage of this approach is that it avoids errors arising from use of inexact exchange rates. Exchange rates prevailing at the time of the transaction should be used for matching transactions involving different currencies. However, for practical reasons, period average exchange rates are often used for this process. 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 balance of payments methodology, which recommends the use of the exchange rate prevailing when a flow takes place or over a very short period of time, not an average rate over a prolonged period.

4.21 In practice, particularly when exchange rates are not volatile, the use of the second methodology may yield results similar to those of the recommended balance of payments methodology. One possible approach (although burdensome) is to collect (by using the midpoint rate applicable to the transactions) data on the value of each transaction in the unit of account and in the currency used in the transaction. If transactions were initially recorded in both the common unit of account and the foreign currency denomination, it would be possible to compile results by using both of the alternative methodologies described earlier. Results from use of the two methods could be compiled from a sample of transactions and compared. While this procedure adds an additional cost to the ITRS, collection of data in both relevant currencies provides a potential cross-check that transactions are correctly recorded; a set of conversion ratio checks could be developed to validate reported data. Any ratio falling outside predetermined limits could be investigated.

Time of Recording

4.22 It is important that banks and FDRs record transactions 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 FDR. 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 cancelled if underlying transactions are cancelled or otherwise not completed.

4.23 Another example could be when a bank receives a draft to be sent for collection—the draft may be recorded when it is purchased from the client, when it is sent for collection, or when it is recorded by the correspondent bank.

4.24 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 views regarding when to record foreign exchange assets. As mentioned earlier, 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. If these items are not included in an ITRS, data covering transactions in excluded assets and liabilities and corresponding positions should be collected separately and included in balance of payments and IIP compilations. 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.

4.25 Even if all banks included all the transactions covered by the assets and liabilities mentioned previously, and chose similar reporting procedures, there nonetheless may be timing discrepancies; for example, two domestic banks involved in a foreign exchange settlement may not record the settlement in the same accounting period. This circumstance could give rise to a discrepancy in the total settlements 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.

4.26 It is important 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

4.27 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 balance of payments methodology 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 balance of payments statement.

4.28 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, or for estimates to be made if the amounts involved are significant.

4.29 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, communication, money transfer operators, financial companies, and companies 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 companies, or it may be necessary to split certain transactions into component parts.

Scope of a Simple ITRS

4.30 A model of a simple closed ITRS is used to illustrate operation of this type of collection system. The model is based on the assumptions that: (1) residents can hold foreign exchange accounts with resident banks; these accounts can be used only for payments to nonresidents; (2) payments in foreign currency between two residents are not allowed; (3) residents cannot hold accounts with nonresident banks; and (4) ITRS is focused on collecting transactions going through banks’ correspondent accounts (nostro / vostro). These assumptions, which would be valid in an economy with foreign exchange controls, are dispensed with later in the chapter. Under these assumptions, four types of foreign exchange transactions may be recorded by resident Bank A:

  • (1) A bank client makes a payment for improved goods in foreign exchange to a nonresident, and receives payment for reselling the goods to another nonresident. Both payment and receipt will be made on the client’s foreign exchange account with Bank A.

  • (2) To travel abroad, a resident individual acquires foreign currency traveler’s checks from Bank A. Bank A purchases traveler’s checks issued by a nonresident bank from a nonresident individual.

  • (3) Bank A undertakes a foreign exchange transaction with a correspondent nonresident bank abroad. These may be foreign exchange transactions or other transactions settled in foreign currency.

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

4.31 Under a closed ITRS, the payments/receipts of foreign exchange by the client will be recorded by the bank on behalf of its client using model form 3-1 and the corresponding reduction/increase in the bank’s foreign exchange position will be recorded in the bank’s transactions through model forms 3-4 and 3-5. The payments and receipts are recorded according to the purpose(s) of the transactions.

4.32 For example, in case (1), if Bank A’s client pays 100 units of foreign exchange (currency y) to purchase goods from abroad and receives 120 units of currency y from selling goods abroad, the following entries would be recorded in a closed ITRS:

Current accountReceipts (Credit)Payments (Debit)
Goods120100
Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Bank, deposits—−100
currency y+ 120

4.33 In case (2), a transaction arises as a result of a domestic bank selling traveler’s checks to a resident traveler. Under the assumption that ITRS is collecting transactions through bank nostro accounts, the purchase of traveler’s checks will be recorded at the time of settlement with the correspondent bank.4

For example, Bank A conducts the following transactions in currency y: purchases 50 units of traveler’s checks (issued by a nonresident bank) from the nonresident travelers and sells 60 units of traveler’s checks issued by the bank to resident traveler. Further, Bank A claims 50 units settlement for the purchased traveler’s checks and pays 60 units as settlement claimed by nonresident banks that purchased traveler’s checks issued by the bank. The appropriate ITRS entries for the settlement transactions are as follows:

Current accountReceipts (Credit)Payments (Debit)
Services—travel5060
Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Bank, deposits—–60
currency y+50

4.34 An example for case (3) would be a foreign currency exchange transaction in which Bank A sells 20 units of currency y for 24 units of currency z to a nonresident bank (one unit of currency y equals 1.2 units of currency z). The appropriate ITRS entries would be:

Financial accountNet acquisition of financial assetsNet incur rence of liabilities
Bank, deposits—−20
currency y
Bank, deposits—+20
currency z
(amount is presented
in currency y)

4.35 Case (3) also covers transactions other than those of a foreign currency exchange nature. For example, Bank A may acquire (at a cost of 5 units of currency y) the services of a nonresident accountant; receive a commission of 6 units on the sale of traveler’s checks issued on behalf of a nonresident bank; and make payments of principal and interest of 37 units and 8 units, respectively, on a loan. Payments for all of these items would be made through Bank A’s foreign exchange account (nostro) with a nonresident bank. The following entries should be recorded in ITRS:

Current accountReceipts (Credit)Payments (Debit)
Services—other5
business services
(accounting)
Services—financial6
Primary income—8
interest
Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Bank—loans−37
Bank, deposits—−5 −8 −37
currency y+6

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

Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Bank, deposits
bank A—currency y−25 −33
bank B—currency y+ 25
central bank—+ 33
currency y

4.37 In all cases described earlier, domestic banks will reduce or increase their holdings of foreign exchange in nostro accounts with nonresident banks.

Aggregation of Results

4.38 Using the examples from the foregoing paragraphs, Table 4.1 illustrates aggregation of the results of an ITRS collection. Initially, results should be compiled by bank and by currency. In aggregation of results, it is important that all significant transactions be recorded; results should be balanced by bank and by currency.

Table 4.1.Summary of ITRS Transactions from Previous Examples (in currency y)
Credit (receipts)Debit (payments)
Summary, bank A, currency y
Current account
Goods120100
Services—
Travel5060
Other65
Primary income8
Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Bank—loans−37
Bank foreign currency−100−60−20−5−8−37−25−33 +120+50+6
Summary, bank A, currency zNet acquisition of financialNet incurrence of liabilities assets
Financial account—
Bank foreign currency+20
Summary, bank A domestic currencyNet acquisition of financial assetsNet incurrence of liabilities
+25+33
Summary, bank B, currency yNet acquisition of financial assetsNet incurrence of liabilities
Financial account—
Bank foreign currency+25
Summary, bank B domestic currencyNet acquisition of financial assetsNet incurrence of liabilities
−25
Summary, central bank, currency yNet acquisition of financialNet incurrence of liabilities
Financial account—assets
Reserve assets+33
Summary, central bank domestic currencyNet acquisition of financial assetsNet incurrence of liabilities
−33
Source: IMF staff.Note: ITRS = international transactions reporting system. The conversion rate of y to z is 1 to 1.2, and of y to domestic currency is 1 to 1. Entries in domestic currency are between two residents and are not reported in ITRS; however they are shown for balancing purposes.
Source: IMF staff.Note: ITRS = international transactions reporting system. The conversion rate of y to z is 1 to 1.2, and of y to domestic currency is 1 to 1. Entries in domestic currency are between two residents and are not reported in ITRS; however they are shown for balancing purposes.

4.39 The next step in the aggregation process is to reconcile flows and positions. Reconciliation can be achieved by comparing opening and closing foreign currency positions (by bank and by currency) with total increase and decrease entries. The opening and closing positions are reported by banks for each monitored account (including nostro and vostro accounts) or aggregated by currency. Table 4.2 shows such reconciliation where the opening position plus increase entries less decrease entries should equal the banks’ closing foreign currency positions (assuming no price or other changes). Any discrepancy discovered in this reconciliation process would be shown in the other changes column. In a closed ITRS, the balance of payments compiler should obtain a full reconciliation; any discrepancy indicates errors or omissions in data. Table 4.2 shows that the sum of increase entries less the sum of decrease entries accounts for the changes in foreign currency positions of the banks shown in Table 4.1; therefore, a full reconciliation has been achieved.

Table 4.2Reconciliation of Opening and Closing Positions with Transactions(in currency y)
Opening foreign currency positionIncreaseDecreaseOther changesClosing foreign currency position
Bank A1.120+196−2881,028
Currency y1,000+176−288888
[+120+50+6][-100-60-20-5
−8-37-25-33]
Currency z120+20140
Bank B
Currency y1,022+251,047
Central bank
Currency y999+331,032
Total3,141+254−2883,107
Source: IMF staff.Note: Values for opening positions are given, not derived from calculations. The conversion ratio of y to z is 1 to 1.2.
Source: IMF staff.Note: Values for opening positions are given, not derived from calculations. The conversion ratio of y to z is 1 to 1.2.

Modifying the Model of the Simple ITRS

4.40 The model of a simple ITRS presented in previous paragraphs is based on assumptions suitable for economies with foreign exchange restrictions. In economies with relaxed or abolished foreign exchange regulations, the system should be modified so that:

  • Residents who have accounts with nonresident banks report details of account transactions and balances.

  • Transactions performed through nonresident accounts with resident banks are monitored. Under a closed ITRS, transactions going through these accounts with both resident and nonresident counterparts will be recorded; however those with a resident counterpart will be classified as neutral.

  • FDRs report details of their noncash transactions, such as the granting of trade credit or loans, with nonresidents and the corresponding positions.

4.41 One important data collection issue for an ITRS is the inclusion of offshore banking units established in an economy. Often the existing regulation in economies classifies offshore companies (banks and nonbanks) as nonresidents. Moreover, offshore banks are usually permitted to accept deposits from, and make loans to, nonresidents only. Offshore banking units should be treated—for purposes of the balance of payments and IIP statistics—as residents of the economies in which they are incorporated. The same treatment should prevail for the nonbank offshore companies incorporated into the economy (see BPM6, paragraphs 4.134 and 4.135, regarding the residence of corporations with little or no physical presence). Consequently, transactions and positions between these companies and nonresidents should be included in an ITRS, and offshore banks should report transactions and corresponding positions with nonresident clients following the same rules as for resident nonoffshore banks. If resident companies 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 balance of payments requirements and that omission or duplication of data is avoided.

Measurement of Noncash Transactions

4.42 A closed ITRS can provide a complete statement of transactions that take place between residents and nonresidents and involve cross border cash payments. This system collects also some noncash transactions that occur between residents and nonresidents and do not involve cash payments. Such transactions are reported by FDRs using the model form 3-3 presented in Appendix 8.

4.43 Examples of noncash transactions that can be recorded by FDRs include exports and imports financed by loans that 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.

4.44 Examples of other noncash transactions cover debt rescheduling, debt cancellation (with the concurrence of both parties), reinvested earnings, dividend to equity conversion, interest and debt to equity conversion, and so forth.

Preparation of a Balance of Payments Statement

4.45 This part presents general issues in compiling a balance of payments statement based on data collected through ITRS. More details on using ITRS data in compiling balance of payments components are described in the subsequent chapters of the Guide dedicated to balance of payments components.

4.46 While most compilers prefer to use international merchandise trade statistics for compiling the goods item in the balance of payments, compilers in some economies use ITRS for the compilation of goods account that may have to be adjusted in a number of ways.

4.47 In respect of coverage, goods financed via loans, goods that form part of foreign aid programs, and goods traded between direct investment enterprises (DIENT) 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. Data sources should be checked for coverage of the counterpart entries, and a corresponding adjustment should be made to the other item in the account if appropriate.

4.48 The value of goods for which prepayment was made or the value of goods sold on short-term credit is recorded in many 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. Also, such reconciliation can be conducted by cross-checking ITRS data on payments for goods with customs declarations data on import and export of goods. Such a reconciliation can be conducted at least for important high-value transactions. 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 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 as follows:

Current accountReceipts (credit)Payments (debit)
Goods240-20-21+23+27
Financial accountNet acquisition of financial assetsNet incurrence of liabilities
Trade credit and−21+20
advances+27−23
Bank, deposits, foreign+240
currency

4.49 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.

4.50 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 balance of payments. In the following example, an aid donor provides food aid to another economy and pays a food producer in the home economy. The resulting balance of payments entries are as follows:

Current accountReceipts (credit)Payments (debit)
For the exporting
economy
Export of goods73
Secondary income—73
transfers (foreign aid)
For the importing
economy
Import of goods73
Secondary income—73
transfers (foreign aid)

4.51 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 trade recorded 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 to enable the valuations to be brought onto an f.o.b. basis.

4.52 In respect of transportation and travel, it is usually necessary to supplement ITRS data on transport and travel companies to ensure that sufficient data are collected and that data are correctly classified. 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.

4.53 Reasonably good-quality statistics on other services can be obtained from an ITRS. These statistics reflect the time at which payment for the services is made rather than when services are rendered. Most compilers who use an ITRS consider payments data to closely approximate data on the time when services were rendered. However, it may be useful for the compiler to obtain information on these relationships to ensure that this view is correct.

4.54 Income should be recorded when it is accrued rather than when it is actually received or paid. Most compilers who use ITRS view payments data as appropriate approximations, in many cases, for time when income is accrued. However, the compiler should adjust ITRS data for reinvested earnings on direct investment and for significant cases in which interest income is accrued and not paid (e.g., 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. 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 are reported as a single item by transactors. This type of reporting is likely to occur, for example, when financial leases are involved, and in these instances the compiler should distinguish between income and loan repayment elements.

4.55 Transfers recorded in ITRS statistics are usually reported at time of payment. Most compilers who use ITRS consider payments data to be reasonable approximations for times when change of ownership occurs 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.

4.56 Financial account transactions measured by ITRS statistics tend to coincide with the balance of payments requirement on time of recording of financial flows—namely, when investment takes place and when drawings and repayments on loans occur. However, the financial account should also include financial transactions that are not captured in an ITRS, such as increases in claims or liabilities due to dividends that are declared payable but not yet paid, or goods or services provided on credit. The compiler may have to supplement ITRS statistics with data on financial transactions that may not be measured by an ITRS (e.g., loans involving trade finance, 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.

4.57 Reserve asset transactions would be included in ITRS statistics if the central bank (or other institution in charge of managing the reserve assets) is one of the ITRS reporters. The reporting by the central bank will be following the same reporting rules as for commercial banks; however, the list of codes for the central bank should include specific codes for transactions on reserve assets (e.g., SDRs holdings, and reserve position with the Fund). However, due to the unique characteristics of reserve assets and the importance of a correct attribution of assets to official reserves, the detailed information on transactions in reserve assets should be collected from the central bank unit in charge of managing the reserve assets.

4.58 To assure the coverage in balance of payments and IIP statistics of transactions that are not covered in ITRS, additional collections should be developed through supplementary forms and added to the basic ITRS. For example, supplementary forms must be developed to measure reinvested earnings on direct investment, transportation, travel, insurance, and so forth. The compiler should cross-check the data collected through additional forms with ITRS data in order to avoid duplication.

Collecting and Processing Data

4.59 This section contains a summary of collection features applicable to ITRS. More details are presented in Chapter 2. Figure 4.1 shows the primary processing activities in a typical ITRS. It depicts a representative system; actual systems may use somewhat different approaches. The figure shows three types of basic input: bank client forms (completed by bank clients or by bank officer based on information provided by client), bank reports (completed by banks), and companies reports (completed by FDRs and PDRs in respect of accounts with nonresident banks, noncash transactions, and positions of external assets and liabilities). Bank client forms are checked by banks that receive the forms and submitted to the balance of payments compiler or introduced in the clients’ report database. Ideally, the client forms for ordering payments should include fields related to balance of payments reporting; that information is stored in the bank’s system. The banks have applications that retrieve those data and provide them to the balance of payments compiler under an agreed format.

Figure 4.1Processing System in a International Transactions Reporting System (ITRS)

4.60 Forms not coded by the client are coded at this stage by the bank officer. The clients’ report database, as well as reports completed by banks, is submitted to the balance of payments compiler. It is very important that the submission be done by electronic means; this reduces the burden on processing data by the compiler. Data are then entered in the compiler’s database and subjected to initial validation—an important step to identify any obvious errors, such as noncompleted fields or inaccurate coding. Also various other quality control procedures are conducted.

4.61 Quality control procedures may include: (1) checking the conversion rate between the foreign currency value and the domestic currency value if both amounts are reported; (2) checking the comparability of patterns of transactions reported by companies from period to period; and (3) listing large transactions likely to affect overall results. Reporting banks or companies may be queried about large transactions; responses may result in amendments to the database. Another quality control procedure consists of reconciling reported positions and flows for individual reporting banks and for individual companies. This procedure involves collating data from all sources and examining residuals—activities that may, in turn, lead to data queries and amendments. Transaction values may then be converted to the domestic currency if the value in domestic currency was not collected.

4.62 Because of the complexity of an ITRS and the volume of transactions covered, a large computer processing system is usually required. To calculate resource requirements in this area, it is important to quantify: (1) the volume of records to be processed; (2) the average number of characters per record to be entered and stored; (3) the numbers of interrogations and tabulations to be submitted and the frequency of submission; and (4) the number of staff necessary to organize the system efficiently.

4.63 Many international transactions reporting systems require large numbers of processing staff to check, code, and enter data. Staff numbers can be reduced significantly if computer processes are used—in particular, electronic transmission of data from provider to compiler. The work of processing staff should be monitored to identify and correct any errors. In some systems, every coder’s work is checked by another. This procedure may be expensive, and the mere checking of one’s work by another may not identify all errors.

4.64 More effective are quality control procedures that tolerate a minor level of error while identifying significant errors and underlying reasons. Procedures for checking all large transactions and a sample of smaller transactions should be developed. The checkers should be highly skilled staff. If the error rate on a sample of checked records exceeds the acceptable level for an individual coder, an additional, larger sample of the coder’s work should be checked. If the error rate on that sample is also found to be beyond tolerance, remedial action should be taken—including, in the extreme case, the recoding of entire batches. This type of quality control procedure is more likely to detect individual weaknesses, improve coder skills, and enhance data quality than complete checking procedures.

4.65 Compiler’s requirements for detailed, timely, and accurate statistics should be emphasized when an ITRS is being developed. The compiler should establish priorities in these areas and the collection strategy should be chosen in accordance with these priorities. For example, the requirement for timely statistics may be best satisfied through judicious use of estimation techniques, which will obviously have an impact on collection strategy.

4.66 An important component of a good ITRS is contact (e. g., through regular meetings) between the compiler and the data providers—particularly banks’ officers and those companies engaging in international transactions of large value. The interaction with data providers can be conducted through small group meetings or through larger seminars for respondents. These seminars could review the report forms and the coding system, and could serve as venue for training respondents on main balance of payments concepts (such as the concept of residence or center of predominant economic interest, functional categories, or financial instruments). The seminars could also discuss the main errors and inconsistencies identified in reported data and adjustments that need to be introduced to the classification system and report forms for improving the reporting. Such interaction facilitates correct classification of transactions and monitoring of individual banks or companies so that data can be checked and verified and the compiler kept abreast of developments affecting the balance of payments.

4.67 The process of summarizing records and analyzing aggregates should include estimation for nonresponse and any ratio expansion used to take thresholds into account. The analysis may reactivate some quality control procedures, which may—in turn—generate new queries and amendments. New aggregates may have to be generated; this is an iterative process. Results are released after the compiler is satisfied with the quality of the data.

4.68Figure 4.1 shows a link between the balance of payments company register and the unit record database. Data from the register may be used to classify transactions by sector and industry. Company reports may provide additional information, such as name changes, for the balance of payments company register. Also shown in the diagram is the important link between bank client forms and the balance of payments register. This link demonstrates the matching of transactions data to companies and the identification of new companies for inclusion on the register.

ITRS as a Data Source

Advantages

4.69 The most significant advantage of the ITRS may be its capability to deliver information to the compiler in a very timely and frequent manner, since data are generally registered at the moment of settlement of the transactions. The use of electronic transmission of reports by the financial system also functions towards the timeliness and frequency of data availability.

4.70 For economies that have an ITRS derived from exchange controls, it is a cost-effective source of data as it uses the well-defined regulatory, institutional, and data reporting framework developed for the exchange control purpose. It is likely to remain cost-effective for the compiling agency even when this control is lifted, assuming that the processing procedures in place remain effective after the abolition of the exchange control.

4.71 Well-structured ITRS in an exchange control regime tend to be accurate, since they are generally based on highly comprehensive data reporting guidelines originally designed for surveillance and thus highly detailed. The compiler’s access to data is usually facilitated by the fact that data providers (generally banks) are under the compiling authority’s (central bank) supervision and therefore subject to legislation regarding data collection and reporting procedures. In case the compiling authority is other than the central bank, the regulatory acts should be in place that would allow the compiler access to primary data provided by banks.

4.72 ITRS that do not have reporting thresholds are, in general, very adequate for compilation of transactions of small amounts, such as income, services, and personal transfers.

Disadvantages

4.73 Misclassification is a frequently identified problem in an ITRS because the biggest part of transactions is classified by intermediaries—banks—on behalf of their clients. However, in a system using direct reporting, the reporters have greater knowledge of their transactions and are able to convey more accurate information regarding foreign counterparts and level of detail.

4.74 The adoption of thresholds, common in most ITRS, represents a high risk of data omission. The higher the thresholds, the more likely it is to incur omissions. Exemption threshold may result in the omission of small value transactions, such as personal transfers. Also, for the compilation of personal transfers, an ITRS, which relies exclusively on remittances sent through formal channels, may present significant omissions as many of these flows go through informal channels.

4.75 ITRS might be a burden on data reporters and banks, especially when it is not a by-product of exchange transactions. Structuring an ITRS for the collection of individual transactions is highly costly. Notwithstanding, after the initial costs of the implementation of the system, its maintenance costs are usually low for both reporters and compilers.

4.76 An ITRS accounts for potential gaps in coverage when exchange controls are loosened and residents transact directly abroad or through companies other than domestic banks. Another example of coverage gap is related to transactions that do not involve payments, such as accumulation of trade credits when the payment is made after the delivery of goods and services.

4.77 In some cases, ITRS register only net amounts instead of gross flows required for the compilation of balance of payments. This arises, for instance, for some transport services, money transfers transactions, and postal network activity.

4.78 Another limitation is that all transactions captured in ITRS (except for data from FDRs) are on a cash basis while the balance of payments methodology recommends the accrual basis of recording.

ITRS sometimes refers to an international transaction reporting system (singular), and sometimes refers to international transactions reporting systems (plural).

In some cases, ITRS also includes nostro accounts with resident banks, for banks that are not licensed to have correspondent accounts with nonresident banks.

A vostro (your) account is another bank’s account with the reporting bank, while a nostro (our) account is the reporting bank’s account with another bank.

If ITRS captures transactions of foreign exchange purchase and sale, this transaction is recorded at the time of the purchase of the traveler’s checks.

    Other Resources Citing This Publication