DCMPS Circular No. 9: Bangladesh Electronic Fund Transfer Network (BEFTN) Operating Rules

Department of Currency Management and Payment Systems Bangladesh Bank Head Office Dhaka DCMPS Circular No. 09/2010 Date :
10 Bhadro 1417
25 August 2010
Managing Director/Chief Executive Officers
All scheduled banks in Bangladesh
Dear Sir,
Bangladesh Electronic Fund Transfer Network
(BEFTN) Operating Rules.
All Scheduled banks of the country that will participate in the Bangladesh Automated Clearing House (BACH) are hereby advised to download the Bangladesh Electronic Fund Transfer Network (BEFTN) Operating Rules for their use. The approved BEFTN Operating Rules is published in the website of Bangladesh Bank. The addresses of the website are:
www.bb.org.bd www.bangladesh-bank.org
They are also requested to execute and sign the Bangladesh Electronic Fund Transfer Network Participant Agreement and Indemnity (Appendix Seven) and send it to the Department of Currency Management and Payment systems, Bangladesh Bank within 30 September, 2010. Please acknowledge receipt. Sincerely Yours, Signed Enclosure: BEFTN Participant Agreement and Indemnity (Appendix Seven). (Jinnatul Bakeya) General Manager Tel: 880-2-7120372 Fax: 880-2-7120373 Email: jinnatul.bakeya@bb.org.bd

Bangladesh Electronic Funds Transfer Network
(BEFTN)
OPERATING RULES
Payment Systems Division
Department of Currency Management and Payment Systems Bangladesh Bank 10 August 2010

FOREWORD
A modern national payment system is the backbone for a country’s monetary and financial infrastructure and an advanced payment system plays a critical role in the country’s current and future economic development. Several years ago, Bangladesh Bank in partnership with the U.K. Department for International Development (DFID) embarked on a project to modernize Bangladesh’s national payments system. The project is multifaceted and its primary objective was to increase and improve the delivery of workers’ remittances. The effort is known as the Remittance and Payments Partnership (RPP). Over the past two years significant progress has been made in achieving the goals of the initiative. The RPP project has two major payment system components consisting of the creation of an inter‐bank electronic funds transfer system which has been named the Bangladesh Electronic Funds Transfer Network (BEFTN) and the automation of the existing paper cheque clearing system which is known as the Bangladesh Automated Cheque Processing System (BACPS). The creation of the Bangladesh Electronic Funds Transfer Network is the most critical component in the development of a modern payments system infrastructure. BEFTN will be the most powerful payments system in Bangladesh. The network will have extensive reach by connecting, for the first time, all of the banks in Bangladesh. This new electronic funds transfer network will provide the foundation for providing access to every banked and non‐banked consumer as well as every business customer to facilitate electronic commerce. No other single electronic network will have the reach of BEFTN. This is a significant advantage over other payments systems being developed in the country. It is also the only payment system that handles a wide variety of credit transfer applications such as payroll, foreign and domestic remittances, social security, dividends, retirement, expense reimbursement, bill payments, corporate payments, government tax payments, veterans payments, government licences and person to person payments as well as debit transfer applications such as mortgage payments, membership dues, loan payments, insurance premiums, utility bill payments, company cash concentration, government tax payments, government licenses and fees. In the future BEFTN will be linked to the mobile payment initiatives currently being developed within Bangladesh, the mobile networks will provide the gateway for the non‐banked to reach banked consumers and businesses and for banked consumers and businesses to reach the non‐banked.

The BEFTN Operating Rules that are contained in this document in conjunction with the recently enacted Bangladesh Payments and Settlement Systems Regulations – 2009 establish the legal foundation needed to support BEFTN. The BEFTN rules define the roles and responsibilities of all of the parties. Each bank will execute a contractual agreement that will bind the bank to comply and adhere to the BEFTN Rules completing the legal underpinning of the system. I would like to take this opportunity to thank DFID, the RPP Advisory Team, and especially George Thomas, the RPP Regulatory Advisor for their contributions in the development of the BEFTN Rules. I would also like to thank the National Automated Clearing House Association (NACHA) of the United States for allowing their ACH rules to be used as the foundation for the BEFTN Rules. Dasgupta Asim Kumar Executive Director & Project Director, Bangladesh Bank, RPP Project 10 August 2010

TABLE OF CONTENTS
INTRODUCTION ............................................................................................................................... 1
BEFTN OVERVIEW................................................................................................................................................... 1

ABOUT BEFTN .............................................................................................................................................. 1
PARTICIPANTS IN BEFTN ............................................................................................................................1
EFT TRANSACTION FLOW.............................................................................................................................2
CONSUMER VS. CORPORATE PAYMENTS .................................................................................................... 5
PAYMENT APPLICATIONS............................................................................................................................. 5
SETTLEMENT AND POSTING.........................................................................................................................6
LEGAL FRAMEWORK .................................................................................................................................... 7
ARTICLE ONE..................................................................................................................................... 9
GENERAL................................................................................................................................................................. 9
SECTION 1.1 Application of Rules ...........................................................................................................................9
SECTION 1.2 Compliance with Rules....................................................................................................................... 9
1.2.1 Compensation................................................................................................................................................ 9
1.2.2 Dispute Resolution........................................................................................................................................ 9
SECTION 1.3 Excused Delay .................................................................................................................................... 9
SECTION 1.4 Days on Which Institution or Facility is Closed .................................................................................. 9
SECTION 1.5 Records .............................................................................................................................................. 9
1.5.1 Records of Entries.......................................................................................................................................... 9
1.5.2 Record Retention........................................................................................................................................... 9
1.5.3 Electronic Records Permitted ...................................................................................................................... 10
SECTION 1.6 Choice of Law...................................................................................................................................10
ARTICLE TWO .................................................................................................................................11
ORIGINATION OF ENTRIES ....................................................................................................................................11
SECTION 2.1 Prerequisites to Origination............................................................................................................. 11
2.1.1 Originator Authorization and Agreement.................................................................................................... 11
2.1.2 Receiver Authorization and Agreement ...................................................................................................... 11
2.1.3 Exception to Authorization Requirement.................................................................................................... 11
2.1.4 Notice by OB................................................................................................................................................11
2.1.5 Notice by RB ................................................................................................................................................12
2.1.6 OB Exposure Limits ......................................................................................................................................12
SECTION 2.2 Warranties and Liabilities of Originating Banks............................................................................... 12
2.2.1 Warranties ................................................................................................................................................... 12
2.2.1.1 Authorization by Originator and Receiver ................................................................................................ 12
2.2.1.2 Timeliness of Entries.................................................................................................................................12
2.2.1.3 Compliance With Other Requirements .................................................................................................... 12
2.2.1.4 Revocation of Authorization.....................................................................................................................13
2.2.1.5 Termination of Authorization by Operation of Law ................................................................................. 13
2.2.1.6 Transmittal of Required Information........................................................................................................ 13
2.2.1.7 Reclamation Entries..................................................................................................................................13
2.2.1.8 Correspondent Bank.................................................................................................................................13
2.2.2 Limitation..................................................................................................................................................... 13
2.2.3 Liability for Breach of Warranty................................................................................................................... 14
SECTION 2.3 Reversing Files .................................................................................................................................14
2.3.1 General Rule ................................................................................................................................................14
2.3.2 Limitations on Initiation of Reversing Files.................................................................................................. 14
2.3.3 Notification by BEFTN Authority.................................................................................................................. 14
2.3.4 Correcting Files ............................................................................................................................................14
2.3.5 Indemnification............................................................................................................................................ 14
2.3.6 Inapplicable Provisions ................................................................................................................................15
SECTION 2.4 Reversing Entries .............................................................................................................................15
2.4.1 General Rule ................................................................................................................................................15

2.4.2 Indemnification............................................................................................................................................ 15
2.4.3 Inapplicable Provisions ................................................................................................................................15
SECTION 2.5 Reclamation Entries.........................................................................................................................15
2.5.1 General Rule ................................................................................................................................................15
2.5.2 Definition ..................................................................................................................................................... 16
2.5.3 Inapplicable Provisions ................................................................................................................................16
SECTION 2.6 Reinitiating Returned Entries by Originators................................................................................... 16
SECTION 2.7 Media and Format Specification Requirements .............................................................................. 16
SECTION 2.8 Release of Information .................................................................................................................... 16
ARTICLE THREE .............................................................................................................................17
OBLIGATIONS OF ORIGINATORS...........................................................................................................................17
SECTION 3.1 General ............................................................................................................................................17
SECTION 3.2 Consumer Accounts—Notice by Originator to Receiver of Variable Debits.................................... 17
3.2.1 Notice of Change in Amount ....................................................................................................................... 17
3.2.2 Receiver’s Election.......................................................................................................................................17
3.2.3 Notice of Change in Scheduled Debiting Date............................................................................................. 17
SECTION 3.3 Record of Authorization...................................................................................................................17
ARTICLE FOUR................................................................................................................................18
RECEIPT OF ENTRIES .............................................................................................................................................18
SECTION 4.1 General Rights and Obligations of RB .............................................................................................. 18
4.1.1 Right to Information Regarding Entries....................................................................................................... 18
4.1.2 Obligation to Accept Entries........................................................................................................................ 18
4.1.3 Reliance on Account Numbers for Posting of Entries.................................................................................. 18
SECTION 4.2 Warranties of Receiving Banks ........................................................................................................ 18
SECTION 4.3 Availability of Entries, Crediting and Debiting of Entries................................................................. 18
4.3.1 Availability of Credit Entries to Receivers.................................................................................................... 18
4.3.2 Time of Debiting of Entries ..........................................................................................................................19
4.3.3 Provision of Payment‐Related Information to Receiver.............................................................................. 19
4.3.4 Crediting of Originators’ Accounts by Receiver........................................................................................... 19
4.3.5 Rights of Receiver Upon Unauthorized Debit to Its Account....................................................................... 19
4.3.6 Reliance on Standard Entry Class Codes...................................................................................................... 19
4.3.7 Reimbursement of RB..................................................................................................................................19
SECTION 4.4 Periodic Statements.........................................................................................................................19
SECTION 4.5 Notice to Receiver............................................................................................................................20
SECTION 4.6 Release of Information .................................................................................................................... 20
SECTION 4.7 Liability of RB for Benefit Payments ................................................................................................ 20
4.7.1 Liability of RB ...............................................................................................................................................20
4.7.2 Amount of RB Liability .................................................................................................................................20
4.7.3 Demand for Payment...................................................................................................................................20
4.7.4 Timing .......................................................................................................................................................... 20
4.7.5 Alteration by Agreement .............................................................................................................................20
ARTICLE FIVE..................................................................................................................................22
RETURN, ADJUSTMENT, CORRECTION, AND ACKNOWLEDGMENT...................................................................... 22
OF ENTRIES AND ENTRY INFORMATION............................................................................................................... 22
SECTION 5.1 Return of Entries..............................................................................................................................22
5.1.1 Right to Return Entries ................................................................................................................................22
5.1.2 Requirements of Returns.............................................................................................................................22
5.1.3 Restrictions on Right to Return.................................................................................................................... 22
5.1.4 Credit Entries Returned by Receiver............................................................................................................ 22
5.1.5 Return of Un‐posted Credit Entries ............................................................................................................. 22
5.1.6 Acceptance of Return Entries by OB............................................................................................................ 22
5.1.7 Re‐initiation of Return Entries by OB........................................................................................................... 23
SECTION 5.2 Dishonour of Return Entries ............................................................................................................ 23

5.2.1 Dishonour of Return by OB.......................................................................................................................... 23
5.2.2 Contesting of Dishonoured Returns by RB .................................................................................................. 23
5.2.3 Contesting a Contested Dishonoured Return.............................................................................................. 23
5.2.4 Corrected Returns........................................................................................................................................23
SECTION 5.3 Notification of Change..................................................................................................................... 23
5.3.1 Notifications of Change; RB Warranties and Indemnity.............................................................................. 23
5.3.2 OB and Originator Action on Notification of Change .................................................................................. 24
SECTION 5.4 Refused Notification of Change ....................................................................................................... 24
5.4.1 OB Right to Refuse Notification of Change Entries...................................................................................... 24
5.4.2 RB Action on Refused Notification of Change ............................................................................................. 24
ARTICLE SIX.....................................................................................................................................25
SETTLEMENT AND ACCOUNTABILITY....................................................................................................................25
SECTION 6.1 Maintenance of Central Bank Account............................................................................................ 25
SECTION 6.2 Settlement .......................................................................................................................................25
SECTION 6.3 Effect of Settlement.........................................................................................................................25
SECTION 6.4 Accountability for Entries ................................................................................................................ 25
SECTION 6.5 Effect of RB Closing on Time of Settlement..................................................................................... 25
SECTION 6.6 Effect of OB Closing on Time of Settlement .................................................................................... 25
ARTICLE SEVEN ..............................................................................................................................26
RECALL, STOP PAYMENT, RECREDIT, AND ADJUSTMENT..................................................................................... 26
SECTION 7.1 Recall by OB or Originator ............................................................................................................... 26
SECTION 7.2 OB Request for Return..................................................................................................................... 26
SECTION 7.3 OB Agrees to Accept a Corporate Debit Return............................................................................... 26
SECTION 7.4 Stop Payment Affecting Consumer Accounts .................................................................................. 26
SECTION 7.5 Stop Payment Affecting Non‐Consumer Accounts .......................................................................... 26
SECTION 7.6 Receiver’s Right to Recredit............................................................................................................. 27
7.6.1 Receiver’s Right to Recredit.........................................................................................................................27
7.6.2 Receiver’s Written Statement ..................................................................................................................... 27
7.6.3 Unauthorized Debit Entry............................................................................................................................27
7.6.4 Waiver of Right to Re‐credit ........................................................................................................................ 27
7.6.5 Effect of Execution of Waiver ...................................................................................................................... 27
7.6.6 Re‐credit Right Not Exclusive.......................................................................................................................28
SECTION 7.7 Adjustment Entries ..........................................................................................................................28
7.7.1 RB’s Right to Adjustment.............................................................................................................................28
7.7.2 Warranty of RB ............................................................................................................................................28
7.7.3 Copy of Written Statement .........................................................................................................................28
7.7.4 Acceptance of Adjustment Entries by OB.................................................................................................... 28
ARTICLE EIGHT ..............................................................................................................................29
OBLIGATIONS OF THE BEFTN AUTHORITY ............................................................................................................ 29
SECTION 8.1 Processing Obligation ......................................................................................................................29
SECTION 8.2 Return and Rejection by BEFTN....................................................................................................... 29
SECTION 8.3 Originator Status Code Review........................................................................................................ 29
SECTION 8.4 Optional Services .............................................................................................................................29
SECTION 8.5 Non‐Settled Entries..........................................................................................................................29
SECTION 8.6 Entries Originated to a RB that Cannot Settle ................................................................................. 29
SECTION 8.7 Entries Received from an OB that Cannot Settle............................................................................. 30
SECTION 8.8 Record of Entries .............................................................................................................................30
ARTICLE NINE .................................................................................................................................31
RESPONSIBILITIES OF BANGLADESH BANK AND BEFTN PARTICIPANTS ............................................................... 31
SECTION 9.1 General ............................................................................................................................................31
SECTION 9.2 Sending Credit and Debit Items ....................................................................................................... 31
SECTION 9.3 Security Procedures.........................................................................................................................31

SECTION 9.4 Sending Bank’s Agreements ............................................................................................................ 32
SECTION 9.5 Processing of Items.......................................................................................................................... 32
SECTION 9.6 Delivery of Items..............................................................................................................................33
SECTION 9.7 Time Schedules, Settlement Dates and Extension of Time Limits ................................................... 34
SECTION 9.8 Designation of Settlement Account................................................................................................. 34
SECTION 9.9 Settlement .......................................................................................................................................35
SECTION 9.10 Availability of Credit....................................................................................................................... 36
SECTION 9.11 Receiving Bank’s Agreements........................................................................................................ 36
SECTION 9.12 Revocation of Items....................................................................................................................... 36
SECTION 9.13 Return of Items and Funds ............................................................................................................ 37
SECTION 9.14 Disputed Returns ...........................................................................................................................37
SECTION 9.15 Advices of Credit and Debit; Reporting of Errors........................................................................... 37
SECTION 9.16 Records ..........................................................................................................................................37
SECTION 9.17 Fees................................................................................................................................................ 37
SECTION 9.18 Non‐Value Messages ..................................................................................................................... 37
SECTION 9.19 Bangladesh Bank Liability .............................................................................................................. 38
SECTION 9.20 As of Adjustments..........................................................................................................................38
SECTION 9.21 Right to Amend..............................................................................................................................38
ARTICLE TEN...................................................................................................................................39
DEFINITION OF TERMS..........................................................................................................................................39
SECTION 10.1 Definitions As Used In These Rules................................................................................................ 39
SECTION 10.2 Construction Rules......................................................................................................................... 41
SECTION 10.3 Other definitions............................................................................................................................42
THE APPENDICES...........................................................................................................................47
TECHNICAL SPECIFICATIONS.................................................................................................................................47
BEFTN PARTICIPATION AGREEMENT .................................................................................................................... 47
APPENDIX ONE ...............................................................................................................................48
BEFTN FILE EXCHANGE SPECIFICATIONS .............................................................................................................. 48
SECTION 1.1 Electronic Transmission Requirements............................................................................................ 48
SECTION 1.2 BEFTN CD/DVD Specifications.......................................................................................................... 48
SECTION 1.3 Data Specifications...........................................................................................................................48
SECTION 1.4 Sequence of Records in BEFTN Files ................................................................................................ 48
SECTION 1.5 File Structure....................................................................................................................................49
SECTION 1.6 Trace Number Sequence in BEFTN Files .......................................................................................... 50
APPENDIX TWO..............................................................................................................................51
BEFTN RECORD FORMAT SPECIFICATIONS ........................................................................................................... 51
SECTION 2.1 BEFTN Record Formats .................................................................................................................... 51
2.1.1 BEFTN File Record Format for All Entries..................................................................................................... 51
2.1.2 BEFTN Batch Record Format for All Entries ................................................................................................. 52
2.1.3 Sequence of Records for ADV Entries.......................................................................................................... 52
2.1.3 Sequence of Records for ADV Entries (continued) ...................................................................................... 53
2.1.4 Sequence of Records for CCD Entries .......................................................................................................... 53
2.1.5 Sequence of Records for CIE Entries............................................................................................................ 54
2.1.6 Sequence of Records for CTX Entries........................................................................................................... 54
2.1.7 Sequence of Records for PPD Entries .......................................................................................................... 55
2.1.8 Sequence of Records for TRX Entries........................................................................................................... 55
SECTION 2.2 Code Values .....................................................................................................................................55
SECTION 2.3 Glossary of File Format Data Elements............................................................................................ 58
APPENDIX THREE..........................................................................................................................59

SPECIFICATIONS FOR DATA ACCEPTANCE ............................................................................................................ 59
SECTION 3.1 File Acknowledgment ......................................................................................................................59
SECTION 3.2 File Level Reject Option ................................................................................................................... 59
SECTION 3.3 Batch Level Reject Option................................................................................................................ 60
SECTION 3.4 Automatic File Rejections ................................................................................................................ 60
SECTION 3.5 Automatic Batch Rejection .............................................................................................................. 60
SECTION 3.6 Automatic Entry Detail Return Entry ............................................................................................... 61
APPENDIX FOUR ............................................................................................................................62
MINIMUM DESCRIPTION STANDARDS ................................................................................................................. 62
APPENDIX FIVE ..............................................................................................................................63
RETURN ENTRIES .................................................................................................................................................. 63
SECTION 5.1 Automated Return Entries............................................................................................................... 63
SECTION 5.2 Non‐Automated Return Entries....................................................................................................... 63
SECTION 5.3 Adjustment Entries ..........................................................................................................................63
SECTION 5.4 Table of Return Reason Codes......................................................................................................... 64
SECTION 5.5 Record Formats for Automated and Converted Return Entries ...................................................... 68
5.5.1 Corporate Entry Detail Record Format for Returns..................................................................................... 68
5.5.2 Entry Detail Record Format for Returns ...................................................................................................... 69
5.5.4 Addenda Record Format for Returns........................................................................................................... 69
SECTION 5.6 Dishonoured Return Entries by BEFTN ............................................................................................ 70
5.6.1 Company/Batch Header Record Format for Automated Dishonoured Returns.......................................... 70
5.6.2 Corporate Entry Detail Record for Automated Dishonoured Returns......................................................... 71
5.6.3 Entry Detail Record Format for Automated Dishonoured Returns ............................................................. 71
5.6.5 Addenda Record Format for Automated Dishonoured Returns.................................................................. 72
SECTION 5.7 Contested Dishonoured BEFTN Return Entries................................................................................ 72
5.7.1 Automated Contested Dishonoured Return Entries.................................................................................... 72
5.7.2 Non‐Automated Contested Dishonoured Return Entries............................................................................ 73
5.7.3 Corrected Return Entries .............................................................................................................................73
5.7.4 Company/Batch Header Record Format for Automated Contested Dishonoured Returns ........................ 73
5.7.5 Corporate Entry Detail Record Format for Automated Contested Dishonoured Returns........................... 74
5.7.6 Entry Detail Record Format for Automated Contested Dishonoured Returns............................................ 74
5.7.7 Addenda Record Format for Automated Contested Dishonoured Returns ................................................ 75
APPENDIX SIX .................................................................................................................................76
NOTIFICATION OF CHANGE ..................................................................................................................................76
SECTION 6.1 Automated Notification of Change.................................................................................................. 76
SECTION 6.2 Non‐Automated Notification of Change.......................................................................................... 76
SECTION 6.3 Refused BEFTN Notification of Change............................................................................................ 76
SECTION 6.4 Minimum Description Standards for Notifications of Change and Corrected Notifications of
Change.................................................................................................................................................................. 76
SECTION 6.5 Table of Change Codes .................................................................................................................... 77
SECTION 6.6 Record Formats for Automated and Converted Notifications of Change........................................ 79
6.6.1 Company/Batch Header Record Format for Notifications of Change ......................................................... 79
6.6.2 Corporate Entry Detail Record Format for Notifications of Change............................................................ 79
6.6.3 Entry Detail Record Format for Notifications of Change ............................................................................. 80
6.6.4 Addenda Record Format for Notifications of Change ................................................................................. 80
6.6.5 Company/Batch Header Record Format for Automated Refused Notifications of Change ........................ 81
6.6.6 Corporate Entry Detail Record Format for Automated Refused Notifications of Change........................... 81
6.6.7 Entry Detail Record Format for Automated Refused Notifications of Change............................................ 82
6.6.8 Addenda Record Format for Automated Refused Notifications of Change ................................................ 82
APPENDIX SEVEN...........................................................................................................................83

BEFTN PARTICIPANT AGREEMENT........................................................................................................................83
APPENDIX EIGHT...........................................................................................................................84
SAMPLE BEFTN ORIGINATION AGREEMENT......................................................................................................... 84

INTRODUCTION
BEFTN OVERVIEW

ABOUT BEFTN
The Bangladesh Electronic Funds Transfer Network (BEFTN) will operate as a processing and delivery centre providing for the distribution and settlement of electronic credit and debit instruments among all participating banks. This Network will operate in a real‐time batch processing mode. Transaction files received from the banks during the day will be processed as they are received to ensure that if there are conditions that would result in a file or batch reject the banking company will have sufficient time to fix the errors and resubmit the file. All payment transactions will be calculated into a single multilateral netting figure for each individual bank. Final settlement will take place using accounts that are maintained with Bangladesh Bank. Participating banks in the EFT Network and the EFT Operator (BEFTN) will be inter‐connected via communication links. The use of a communication network facilitates the transmission of payments information that provides faster, safer and a more efficient means of inter‐bank clearing than would be possible using the existing paper‐based system. BEFTN will provide the capability to offer a wide range of electronic products that will improve payment services for the participating banks’ customers. BEFTN will dramatically lower the operational cost, reduce risk and will also increase the efficiency of the overall payment process.
PARTICIPANTS IN BEFTN
The EFT Network is a multilateral electronic clearing system in which electronic payment instructions will be exchanged among Scheduled Banks. The system involves transmitting, reconciling and calculating the net position of each individual participant at the end of each processing cycle. The participants involved are:
(a) Originator.
(b) Originating Bank (OB)
(c) Bangladesh Electronic Funds Transfer Network (EFT Operator) (d) Receiving Bank (RB) (e) Receiver (f) Correspondent Bank a) Originator The Originator is the entity that agrees to initiate EFT entries into the network according to an arrangement with a receiver. The originator is usually a company, government agency or an individual directing a transfer of funds to or from a consumer’s or a company’s account. The originator executes an EFT fund transfer entry through an Originating Bank (OB). b) Originating Bank (OB) The originating bank is the bank which receives payment instructions from its client (the originator) and forwards the entry to the BEFTN. A bank may participate in the EFT system as a receiving bank without acting as an originating bank; however, if a Bank chooses to originate EFT entries, it must also agree to act as a receiving bank. c) Bangladesh Electronic Funds Transfer Network (BEFTN) BEFTN is the central clearing facility, operated by Bangladesh Bank that receives entries from OBs, distributes the entries to appropriate RBs, and facilitates the settlement functions for the participating banking institutions

d) Receiving Bank (RB)
The receiving bank is the bank that will receive EFT entries from BEFTN and post the entries to the account of its depositors (Receivers). e) Receiver A receiver is a person/organization who has authorized an Originator to transmit an EFT entry to the account of the receiver maintained with the Receiving Bank (RB). f) Correspondent Bank In some cases an Originator, Originating Bank or Receiving Bank may choose to use the services of a Correspondent Bank for all or part of the process of handling EFT entries. A Correspondent Bank’s function can include, but is not limited to, the creation of EFT files on behalf of the Originator or acting on behalf of an OB or RB, respectively. All Correspondent Banks must be approved by Bangladesh Bank before a bank enters into an agreement with the Correspondent Bank.
Figure 1: Participants involved in an EFT transaction
Authorization
A written arrangement with the originating company signed by an employee or customer to allow payments processed through the EFT Network to be deposited in or withdrawn from his or her account at a bank. Authorization can also be a written agreement that defines the terms, conditions and legal relationship between Originator and Receiver.
3. EFT TRANSACTION FLOW
In EFT terminology, Originator and Receiver refer to the participants that initiate and receive the EFT entries rather than the funds. Unlike a check, which is always a debit instrument, an EFT entry may either be a credit or a debit entry. By examining what happens to the receiver’s account, one can distinguish between an EFT Credit and EFT Debit transaction. If the receiver’s account is debited, then the entry is an EFT debit. If the receiver’s account is credited, then the entry is an EFT credit. Conversely, the offset of an EFT debit is a credit to the originator’s account and the offset to an EFT credit is a debit to the Originator’s account. In the later sections the description of the transaction and/or instruments to be used in the BEFTN has been described in logical sequence regardless of their implementation schedule. Authorization BEFTN Bangladesh Bank (Reporting & Settlement) Originating Bank Originator Receiver Receiving Bank

a) EFT Credits
EFT credit entries occur when an Originator initiates a transfer to move funds into a Receivers account. For example, when a corporate uses the payroll service at a bank to pay the salary of its employee each month, the corporate originates the payment through the OB to transfer the money into the account of the employee; the individual is the receiver in this example. EFT credit transactions involve both consumer and corporate payments with separate rules and regulations for each. The most typical consumer EFT application is Direct Deposit of Payroll.

In the illustration above an EFT credit transaction flow for payroll payment is shown, where an organization initiates an EFT entry to credit its employee’s account. Some other common credit applications are:

Inward Foreign remittances
Domestic remittances
Payroll private and government
Dividends/Interest/Refunds of IPO
Business to business payments (B2B)
Government tax payments
Government vendor payments
Customer‐initiated transactions
b) EFT Debits
In an EFT debit transaction, funds flow in the opposite direction to the information. Funds are collected from the Receiver’s account and transferred to an Originator’s account, even though the originator initiates the entry. BEFTN Receiver Originator TK Debit TK Credit TK Originating Bank
Figure 2: EFT Credit Transactions Flow
Receiving Bank

In the illustration below it is shown that a utility company initiates an EFT entry to collect its bill from the consumer. Some examples of EFT debit application:

Utility bill payments
Equal Monthly Installments (EMI)
Government tax payments
Government license fees
Insurance premium
Mortgage payments
Club/Association subscriptions
A typical transaction as it flows through the EFT Network might follow the path described below:
The Originator and its bank (OB) determine by agreement that how the information will be delivered from the originator to the OB. Ideally, the originating bank or originator would format the data in accordance with the BEFTN prescribed format and transmit the information to the OB via a communication line. The OB generally removes “on‐us” entries (if any) and transmits the remaining entries to the BEFTN within the preset timeline. An “on‐us” transaction is one in which the Receiver and the Originator both have accounts at the same bank. Therefore, the transaction needs not to be sent through BEFTN but instead may be simply retained by the bank and posted to the appropriate account. The BEFTN will sort the entries by Receiving Bank (RB) routing number and transmit the payment information to the appropriate RB for posting. On settlement date/time, BEFTN will calculate the net settlement figure for each participating bank and the settlement will take place at the books of accounts of Bangladesh Bank. BEFTN Receiver Originator TK Credit Originating Bank TK
Figure 3: EFT Debit Transactions Flow
Receiving Bank
TK
Debit

CONSUMER VS. CORPORATE PAYMENTS
EFT transactions are typically categorized as either consumer payments, Government payments or commercial payments. These transactions are defined in accordance with the relationship of parties involved in the transaction and the type of receiver account. Consumer payments that could be made via the EFT network include credit applications such as payroll, dividend, interest and annuity payments and so on. Consumer EFT debit applications include the collection of utility bills, insurance premiums, loan installments and other recurring obligations. Corporate EFT applications include cash collection and disbursement, corporate trade payments, government. tax payments etc. Cash collection and disbursement allows companies to achieve efficiency in cash management through intra‐company transfer of funds. Corporate trade payments enable corporations to exchange both data and funds with trading partners, facilitating an automated process of updating their accounts receivable and accounts payable systems.
PAYMENT APPLICATIONS
The BEFTN will support a variety of payment applications. An Originator initiating entries into the system will code the entries in such a manner as to indicate the type of payment, such as a debit or a credit, and whether an entry is a consumer or corporate in nature. Each EFT application is identified and recognized by a specific three‐digit code, which will be termed as Standard Entry Class (SEC) Codes, which appear in the EFT batch record format and are used to carry the payment and payment‐related information relevant to the application. Following is a list of SEC codes and the different products each code supports.
I. Consumer Applications

CIE – Customer Initiated Entry: Customer initiated entries are limited to credit applications
where the consumer initiates the transfer of funds to a company or person for payment of funds owed to that company or person, typical example of these entries are utility bill and other Internet banking product payments.
PPD – Prearranged Payment and Deposit Entry
Direct Deposit: Direct deposit is a credit application that transfers funds into a consumer’s account at the receiving bank. The funds being deposited can represent a variety of products such as payroll, remittances, interest, pension, dividends and/or refunds, etc. Preauthorized Bill Payment: A preauthorized payment is a debit application. Companies with existing relationship with the customers may participate in the EFT through the electronic transfer (direct debit) of bill payment entries. Through standing authorizations, the consumer grants the company authority to initiate periodic charges to his or her account as bills become due. This concept is especially applicable in situations where the recurring bills are regular and do not vary in amount such as insurance premiums, loan installments, etc. Standing authorization may also used for bills where the amount does vary, such as utility payments.
II. Corporate Applications
CCD – Corporate Credit or Debit: This application can be either a credit or a debit application
where funds are either distributed or consolidated between corporate entities or government entities. This application can serve as a stand‐alone fund transfer between corporate or government entities, or it can support a limited disclosure of information when the funds are being transferred between organizations (i.e. sister concerns) under the same group.
CTX ‐ Corporate Trade Exchange: This application supports the transfer of funds (debit or credit)
within a trading partner relationship in which business payment remittance information is sent with the funds transfer. The payment‐related information is placed in multiple addenda records

in a format agreed to by the parties and BEFTN.
III. Other Applications

ADV – Automated Accounting Advice: This SEC Code represents an optional service to be
provided by BEFTN that identifies automated accounting advices of EFT accounting information in machine‐readable format to facilitate the automation of accounting information for Participating Banks.

SETTLEMENT AND POSTING
Settlement is the actual transfer of the funds between participating banks to complete the payment instruction of an EFT entry. The transactions processed by the BEFTN will affect the accounts of the concerned banks maintaining accounts with BB at the end of each processing cycle. Settlement will be completed using the following processing schedule:
Processing Window Cut Offs
Item Submission Returns Settlement
Normal Processing 00:00 ‐ 24:00 hrs As provided in BEFTN Rules 10:00 hrs Next Day

Settlement and processing sessions may be reviewed and communicated to member banks by the Clearing House (BACH) authority from time to time. The following are the three main participants and their responsibilities concerning settlement and posting.

Originating Bank: Settlement with the OB for entries originated will follow the same procedures
used for settlement of entries received. If the scheduled settlement date of a credit entry is not a banking day for the OB, but the BB office is open, then the settlement will occur on the scheduled date. Specific procedures and timing of settlement between the OB and the originator are solely at the discretion of the OB and the originator and therefore, governed by agreement between them. It is the OB‘s responsibility to monitor the credit‐worthiness of its corporate customers to ensure that the OB‘s risk in originating EFT payments is managed efficiently.
EFT Operator (BEFTN): BEFTN will calculate net settlement figures for each participating bank.
BEFTN will also provide information to participating banks on the amounts that will be settled for each bank on each settlement date. BEFTN will also send a summary statement which contains the net amount to be settled for each participating bank to the Deposit Accounts Bibagh (DAB) of Bangladesh Bank.
Receiving Bank (RB)
a) Posting: The RB is responsible for posting entries and for providing funds availability, both of which are determined by the settlement date in the batch header record. EFT Debits will be delivered to a RB not earlier than one banking day prior to the settlement date. The rule clearly mentions that debit entries cannot be posted prior to the settlement date. If the RB is closed for business on the scheduled settlement date of a debit entry, but the

BEFTN is open, the RB will be debited on the scheduled settlement date unless it has advised the BEFTN to delay settlement to the next business day of the RB. If BEFTN agrees to delay settlement, the RB must pay for any costs for float resulting from the deferral of settlement. EFT Credits will be delivered to a RB not earlier than one working day prior to the settlement date. b) Settlement Settlement between the originator and the OB is governed by agreement. Settlement between the RB and the receiver is determined by these Rules. If BEFTN determines that the entry cannot be settled on the effective entry date due to a stale date, weekend, or holiday, the BEFTN authority will insert the Julian date of the next business day into the settlement date filed, reflecting that settlement will occur on that day.

Settlement information is produced by BEFTN as the entries are processed. This
information is accumulated based on the type of entry (debit or credit) by settlement date. These settlement totals are reported to the participating banks daily.
BEFTN may provide EFT settlement information in a machine‐readable format to
facilitate the automation of settlement accounting for correspondent banks.
Settlement totals should be balanced daily against totals posted to the participating
bank’s customer accounts and against any rejects that may occur. Rejects and other differences must be resolved immediately.
EFT settlement procedures are the same for consumer and corporate transactions. In
view of the large‐value payments that flow through the EFT network for corporate customers, participating banks should have internal procedures in place to monitor large‐value settlements totals.

LEGAL FRAMEWORK
The EFT process operates from beginning to end through a series of legal agreements. Before any transaction is initiated via EFT network, the originator and OB execute an agreement to use BEFTN to originate payments. Among other things, the agreement should bind the originating company or individual to the BEFTN Rules, define the parameters of the relationship between the two parties, and identify processing requirements for the specific application(s), and establish liability and accountability for procedures related to certain application(s). While this BEFTN Rulebook is the primary document addressing the rules and the regulations for the activities of the EFT network, Government’s EFT transactions may be governed by other codes of conduct but they must accommodate the provisions laid down in these Rules. Other laws/regulations that have a direct bearing on EFT operation are listed as under:

Bangladesh Bank Order, 1972 (Amended 2003)
The Banks Companies Act, 1991
Money Laundering Prevention Act, 2009
Information and Communication Technology Act, 2006.
The Bankruptcy Act, 1997
The Foreign Exchange Guidelines, Volume 1 & 2.
Foreign Exchange Regulation Act, 1947.
The Bangladesh Telecommunication Act, 2001.
Anti Terrorism Act 2009
Bangladesh Payment and Settlement Systems Regulations, 2009

ARTICLE ONE
GENERAL

SECTION 1.1 Application of Rules
These rules apply to all entries and entry data transmitted through BEFTN, except where superseded by operating rules by which an OB and RB have agreed to be bound.
SECTION 1.2 Compliance with Rules
Each Participating Bank must agree to comply with these Rules and warrants that it is legally able to comply with all applicable requirements of these Rules.
1.2.1 Compensation
The settlement of claims for compensation between Participating Banks will be governed by the procedures contained in the Bangladesh Automated Clearing House (BACH) Rules on Compensation.
1.2.2 Dispute Resolution
The settlement of disputes arising under these Rules between Participating Banks will be governed by the procedures contained in the Bangladesh Automated Clearing House (BACH) Dispute Resolution Procedures.
SECTION 1.3 Excused Delay
Delay by a Participating Bank or the BEFTN beyond the time limits prescribed or permitted by these Rules is excused if the delay was caused by the interruption of communication or computer facilities, suspension of payments by another Participating Bank, war, emergency conditions, failure of equipment, or other circumstances beyond the control of the Participating Bank or the BEFTN, provided it exercises such diligence as the circumstances require.
SECTION 1.4 Days on Which Institution or Facility is Closed
Any entry or entry data required by these Rules to be made available or transmitted by a Participating Bank or the BEFTN on or by a day that is not a Banking day for both the sending party and receiving party may be made available or transmitted on the next day that is a Banking day for both the sending and receiving parties. This rule only applies where an entry will be received on the same day it is transmitted.
SECTION 1.5 Records
1.5.1 Records of Entries
Each Participating Bank must retain records of all entries, including return and adjustment entries, transmitted from or to the BEFTN. These records must be retained for six years from the date the entry was transmitted. The Participating Bank must, if requested by its customer, or the Receiving Bank, or the BEFTN, provide the requester with a printout or reproduction of the information relating to the entry.
1.5.2 Record Retention
Any agreement, authorization, written statement, or other record required by these Rules

may be retained as the original copy or as an electronic record that (1) accurately reflects the information in the record, and (2) is capable of being accurately reproduced for later reference, whether by transmission, printing, or otherwise.
1.5.3 Electronic Records Permitted
Any agreement, authorization, written statement, or other record required by these Rules to be in writing may instead be in electronic form. Any record that is required to be signed or similarly authenticated may be signed with an electronic signature in conformity with the terms of the Information Technology Act 2006 and in a manner that evidences the identity of the person who signed and that person’s assent to the terms of the record.
SECTION 1.6 Choice of Law
These rules and the rights and obligations of a party with regard to EFT entries shall be construed in accordance with and governed by the laws of The People's Republic of Bangladesh, unless otherwise provided in an agreement of such party.

ARTICLE TWO
ORIGINATION OF ENTRIES

SECTION 2.1 Prerequisites to Origination
The following must occur before an Originator may initiate the first credit or debit entry to a Receiver’s account with a RB:
2.1.1 Originator Authorization and Agreement
The Originator has authorized the OB to transmit, and to credit or debit the amount of, one or more entries to the Receiver’s account. For all entries, the Originator and OB have entered into an agreement under which the Originator agrees to be bound by these Rules as in effect from time to time and acknowledges that entries may not be initiated that violate the laws of The People's Republic of Bangladesh.
2.1.2 Receiver Authorization and Agreement
The Receiver has authorized the Originator to initiate the entry to the Receiver’s account. In the case of debit entries to a commercial account, the Receiver has an agreement with the Originator under which the Receiver has agreed to be bound by these Rules as in effect from time to time. In the case of debit entries to a Consumer Account, the authorization must be in writing and signed or similarly authenticated by the consumer. The similarly authenticated standard permits signed, written authorizations to be provided electronically. The writing and signature requirements are satisfied by compliance with the Information Technology Act 2006 (as contracts or other records created, generated, sent, communicated, received, or stored by electronic means) and electronic signatures. Electronic signatures include, but are not limited to, digital signatures and security codes. The authorization process must evidence both the consumer’s identity and his assent to the authorization. To meet the requirement that an authorization be in writing, an electronic authorization must be able to be displayed on a computer screen or other visual display that enables the consumer to read the communication. The authorization also must be readily identifiable as an authorization, must clearly and conspicuously state its terms, and, for all entries, the authorization must provide that the Receiver may revoke the authorization only by notifying the Originator in the manner specified in the authorization. In the case of credit entries, the authorization may be provided orally or by other non‐written means.
2.1.3 Exception to Authorization Requirement
If both the Originator and Receiver are natural persons, no authorization by the Receiver is required for credit entries, and no warranty with respect to that authorization is made by the OB. The provisions of section 3.3.3 (Record of Authorization), and subsection 4.1.1 (Right to Information Regarding Entries) are not applicable to the entries described in this subsection 2.1.3.
2.1.4 Notice by OB
In the case of a credit entry, the OB shall have provided the Originator with notice of the following:
(1) the entry may be transmitted through the BEFTN;

(2) the rights and obligations of the Originator concerning the entry shall be governed by and construed in accordance with the laws of The People's Republic of Bangladesh; (3) if the RB does not receive such payment for the entry, the RB is entitled to a refund from the Receiver in the amount of the credit to the Receiver’s account, and the Originator will not be considered to have paid the amount of the credit entry to the Receiver. This notice may be included as part of an agreement entered into by the Originator binding the Originator to these Rules, or it may be provided to the Originator separately.
2.1.5 Notice by RB
In the case of a credit entry, the RB has provided the Receiver with notice of the following information:
(1) the rights and obligations of the Receiver concerning the entry shall be governed by and construed in accordance with the laws of The People's Republic of Bangladesh; (2) credit given by the RB to the Receiver for the entry as provided by subsection 4.4.1 (Availability of Credit Entries to Receivers) is provisional until the RB has received final settlement through the Bangladesh Bank; (3) if the RB does not receive such payment for the entry, the RB is entitled to a refund from the Receiver in the amount of the credit to the Receiver’s account, and the Originator will not be considered to have paid the amount of the credit entry to the Receiver; and (4) these Rules do not require the RB to provide the Receiver with notice that the RB has received the entry unless the RB has agreed to do so.
2.1.6 OB Exposure Limits
In the case of an entry initiated by an Originator that is not a natural person, the OB has (1) established an exposure limit for that Originator, (2) implemented procedures to review that exposure limit periodically, (3) implemented procedures to monitor entries initiated by that Originator relative to its exposure limit across multiple settlement dates.
SECTION 2.2 Warranties and Liabilities of Originating Banks
2.2.1 Warranties
Each OB sending an entry warrants the following to each RB and the BEFTN:
2.2.1.1 Authorization by Originator and Receiver
Each entry transmitted by the OB to BEFTN is in accordance with proper authorization provided by the Originator and the Receiver.
2.2.1.2 Timeliness of Entries
Each credit entry is timely, and each debit entry is for an amount which on the Settlement Date will be due and owing to the Originator from the Receiver, is for a sum specified by the Receiver to be paid to the Originator, or is to correct a previously transmitted erroneous credit entry.
2.2.1.3 Compliance With Other Requirements
All other applicable requirements of section 2.1 (Prerequisites to Origination) concerning the authorization of an entry have been satisfied, the entry has not been

reinitiated in violation of section 2.7 (Re‐initiation of Returned Entries by Originators), and the entry otherwise complies with these Rules.
2.2.1.4 Revocation of Authorization
At the time the entry is transmitted to the BEFTN, the Originator’s authorization has not been revoked, the agreement between the OB and the Originator concerning the entry has not been terminated, and neither the OB nor the Originator has actual knowledge of the revocation of the Receiver’s authorization or of the termination of the arrangement between the RB and the Receiver concerning the entry.
2.2.1.5 Termination of Authorization by Operation of Law
At the time the entry is processed by a RB, the authorization for that entry has not been terminated, in whole or in part, by operation of law. This subsection shall not apply if the RB has actual knowledge of the circumstances giving rise to such termination at the time it processes the entry and the OB does not have such actual knowledge.
2.2.1.6 Transmittal of Required Information
Each entry transmitted by the OB to BEFTN contains the correct Receiver account number and all other information necessary to enable the RB to comply with the requirements of section 4.5 (Periodic Statements) except for information within the purview of the RB’s relationship with the Receiver. Information transmitted with an entry is payment‐related and conforms to the requirements of Appendix Two (BEFTN Record Format Specifications).
2.2.1.7 Reclamation Entries
(a) In the case of a reclamation entry initiated pursuant to section 2.5 (Reclamation ntries) or a written demand for payment initiated pursuant to section 4.7 (Liability of RB for Benefit Payments), all information is accurate and applies to the Receiver and account identified in the reclamation entry or written demand; (b) Each such reclamation entry or written demand for payment falls within the time requirements of section 4.7.4 (Timing), has been properly authorized by the intended Receiver of the reclamation entry or written demand, and the authorization for the entry or written demand has not been revoked or otherwise terminated at the time it is received by the RB; (c) Any payments subject to section 4.7 are made with no restriction on the number of parties having an interest in the account.
2.2.1.8 Correspondent Bank
An entry containing the routing number of an OB which is transmitted to the EFT Operator by another member bank to the EFT Operator on its behalf is transmitted pursuant to an agreement entered into between the OB and that service provider bank to transmit the entry.
2.2.2 Limitation
Notwithstanding anything in these Rules to the contrary, the warranties contained within subsection 2.2.1 (Warranties) and the requirements of subsection 2.1.2 (Receiver Authorization and Agreement) do not apply to the goods or services to which the entry relates.

2.2.3 Liability for Breach of Warranty
Each OB breaching any of the preceding warranties shall indemnify every RB and the BEFTN from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, that result directly or indirectly from the breach of warranty or the debiting or crediting of the entry to the Receiver’s account. This indemnity includes, without limitation, any claim, demand, loss, liability, or expense based on the ground that the debiting of an entry to an account resulted, either directly or indirectly, in the return of one or more items or entries of the Receiver due to insufficient funds. This indemnity also includes, in the case of a Consumer Account, without limitation, any claim, demand, loss, liability, or expense based on the ground that the failure of the OB to comply with any provision of these Rules resulted, either directly or indirectly, in the violation by a RB of any applicable law.
SECTION 2.3 Reversing Files
2.3.1 General Rule
If an Originator, OB, or BEFTN has mistakenly initiated a duplicate file or a file in which each entry or each entry in one or more batches contains erroneous data, and no right to recall those entries otherwise exists under these Rules, the Originator, OB, or BEFTN may initiate a file of entries (referred to as a “reversing file”) in accordance with Appendix Two (BEFTN Record Format Specifications) and this section 2.3 to reverse each entry of the duplicate or erroneous file or batch(es).
2.3.2 Limitations on Initiation of Reversing Files
Each reversing file must be initiated in such time as to be transmitted or made available to the RB(s) within five Banking days after the Settlement Date of the duplicate or erroneous file or batch(es). In the case of a reversing file initiated by an Originator or OB, the file must be transmitted to the BEFTN within 24 hours of the discovery of the duplication or error. In the case of a reversing file initiated by the BEFTN, the file must be transmitted to the appropriate RB within 24 hours of the discovery of the duplication or error.
2.3.3 Notification by BEFTN Authority
At or prior to the time of initiation, the BEFTN Authority initiating a reversing file shall notify each RB and each OB directly concerned of the duplication or error.
2.3.4 Correcting Files
A reversing file to correct an erroneous file or batch must be accompanied by a file (referred to as each OB or BEFTN Authority that initiates a reversing or correcting file shall indemnify every Participating bank from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, that result directly or indirectly from the debiting or crediting of any entry in the file to the Receiver’s account. Each OB also shall indemnify every RB from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting directly or indirectly from the crediting or debiting of any entry contained in a reversing or correcting file initiated by an Originator through the OB.
2.3.5 Indemnification
Each OB that initiates a reversing or correcting file shall indemnify every Participating bank from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, that result directly or indirectly from the debiting or crediting of any entry in the file to the Receiver’s account. Each OB also shall indemnify every RB from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting

directly or indirectly from the crediting or debiting of any entry contained in a reversing or correcting file initiated by an Originator through the OB.
2.3.6 Inapplicable Provisions
For a reversing file complying with the requirements of this section, the provisions of sections 2.1 (Prerequisites to Origination), 2.2 (Warranties & Liabilities of OBs), and 3.2 (Consumer Accounts—Notice by Originator to Receiver of Variable Debits) do not apply. A “correcting file”, which contains correct information. The correcting file must comply with the requirements of Appendix Two (BEFTN Record Format Specifications).
SECTION 2.4 Reversing Entries
2.4.1 General Rule

An Originator may initiate an entry (referred to as a “reversing entry”) to correct an erroneous credit or debit entry previously initiated to a Receiver’s account. The reversing entry must be transmitted to the BEFTN in such time as to be transmitted or made available to the RB by midnight of the fifth Banking day following the Settlement Date of the erroneous entry. For this section 2.5 only, an erroneous entry is defined as an entry that (1) is a duplicate of an entry previously initiated by the Originator or OB; (2) orders payment to or from a Receiver not intended to be credited or debited by the Originator; or (3) orders payment in an amount different than was intended by the Originator. The Originator must notify the Receiver of the reversing entry and the reason for the reversing entry no later than the Settlement Date of the reversing entry.
2.4.2 Indemnification
Each OB that initiates a reversing entry shall indemnify every Participating Bank and the BEFTN Authority from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, that result directly or indirectly from the debiting or crediting of the reversing entry to the Receiver’s account. Each OB also shall indemnify every RB and the BEFTN Authority from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, that result directly or indirectly from the crediting or debiting of a reversing entry initiated by an Originator through the OB.
2.4.3 Inapplicable Provisions
For a reversing entry complying with the requirements of Section 2.5, the provisions of sections 2.1.2 (Receiver Authorization and Agreement), 2.2.1.1 (Authorization by Originator and Receiver), 2.2.1.4 (Revocation of Authorization), 2.2.1.5 (Termination of Authorization by Operation of Law), and 3.3 (Consumer Accounts—Notice by Originator to Receiver of Variable Debits) do not apply.
SECTION 2.5 Reclamation Entries
2.5.1 General Rule
An Originator or OB may initiate a reclamation entry in accordance with the requirements of
Section 2.6, section 4.7 (Liability of RB for Benefit Payments), and Appendix Two (BEFTN
Record Format Specifications).

2.5.2 Definition
A reclamation entry must contain an amount equal to or less than the pension, annuity, or other benefit payment to which the reclamation entry relates, as provided for in section 4.7 (Liability of RB for Benefit Payments).
2.5.3 Inapplicable Provisions
For a reclamation entry complying with the requirements of Section 2.6, the provisions of sections 2.2.1.2 (Timeliness of Entries), 2.2.1.4 (Revocation of Authorization), 2.2.1.5 (Termination of Authorization by Operation of Law), and 3.3 (Consumer Accounts—Notice by Originator to Receiver of Variable Debits) do not apply.
SECTION 2.6 Reinitiating Returned Entries by Originators
An entry that has been returned may not be reinitiated unless (1) the debit entry has been returned for insufficient or uncollected funds; (2) the entry has been returned for stopped payment and reinitiating the return entry has been authorized by the Receiver; or (3) the OB has taken corrective action to remedy the reason for the return. An entry that has been returned for insufficient or uncollected funds may be reinitiated no more than two times following the return of the original entry.
SECTION 2.7 Media and Format Specification Requirements
Each entry transmitted by an OB to the BEFTN must comply with the requirements of and be identified by the appropriate Standard Entry Class Code specified in Appendix Two (BEFTN Record Format Specifications).
SECTION 2.8 Release of Information
Each OB agrees that the BEFTN may release to any/concerned department of Bangladesh Bank data regarding EFT return entries transmitted to or by the OB.

ARTICLE THREE
OBLIGATIONS OF ORIGINATORS

SECTION 3.1 General
In addition to the requirements of section 2.1 (Prerequisites to Origination) concerning the initiation of entries, an Originator must comply with the requirements contained within this Article Three.
SECTION 3.2 Consumer Accounts—Notice by Originator to Receiver of Variable Debits
3.2.1 Notice of Change in Amount
If the amount of a debit entry to be initiated to a Consumer Account differs from the amount of the immediately preceding debit entry relating to the same authorization or from a preauthorized amount, the Originator must send the Receiver written notification of the amount of the entry and the date on or after which the entry will be debited.
3.2.2 Receiver’s Election
If the Originator informs the Receiver of the Receiver’s right to receive notification concerning a change in the amount of a debit entry, the Receiver may choose to receive notice only if the amount of the entry falls outside a specified range or if the entry differs from the most recent entry by more than an agreed upon amount.
3.2.3 Notice of Change in Scheduled Debiting Date
If an Originator changes the date on or after which entries to be initiated by the Originator are scheduled to be debited to a Receiver’s account, the Originator shall send to the Receiver written notification of the new date on or after which entries initiated by the Originator are scheduled to be debited to the Receiver’s account. Such notification shall be sent within not less than seven calendar days before the first entry to be affected by the change is scheduled to be debited to the Receiver’s account. For purposes of this subsection 3.2.3, the variation in debiting dates due to holidays is not considered to be changes in the scheduled dates.

SECTION 3.3 Record of Authorization
An Originator must retain the original or an image copy of each authorization of a Receiver for two years from the termination or revocation of the authorization. At the request of its OB, the Originator must provide the original or copy of the authorization to the OB for its use or for the use of a RB requesting the information pursuant to subsection 4.1.1 (Right to Information Regarding Entries).

ARTICLE FOUR
RECEIPT OF ENTRIES
SECTION 4.1 General Rights and Obligations of RB
4.1.1 Right to Information Regarding Entries
Prior to acting as a RB for a Receiver, the RB may request, in writing, that an OB provide a copy of the Receiver’s authorization for any entries other than credit entries. Upon receipt of the RB’s written request, the OB must obtain the original or a copy of the Receiver’s authorization from the Originator in accordance with section 3.4 (Record of Authorization) and provide it to the RB within ten Banking days. An OB must provide such authorization without charge. The RB must not require the Originator to provide any other information concerning the Receiver or any entry to be initiated by the Originator to the Receiver’s account. This subsection 4.1.1 does not apply to entries if the OB and RB are parties to an agreement (other than these Rules) for the provision of services relating to such entries.
4.1.2 Obligation to Accept Entries
Subject to its right to return or reject entries under these Rules, a RB must accept credit and debit entries that comply with these Rules and are received with respect to any account maintained with that RB.
4.1.3 Reliance on Account Numbers for Posting of Entries
If the account number and the name of the Receiver contained in an entry do not relate to the same account, the RB may rely solely on the account number contained in the entry for purposes of posting the entry to the Receiver’s account.
SECTION 4.2 Warranties of Receiving Banks
Each RB warrants to each OB and the BEFTN that it has the power under applicable law to receive entries as provided in these Rules and to comply with the requirements of these Rules concerning RBs and Participating Banks. Any RB breaching any warranty under this section 4.2 shall indemnify each OB, BEFTN Authority from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting directly or indirectly from the breach of warranty.
SECTION 4.3 Availability of Entries, Crediting and Debiting of Entries
4.3.1 Availability of Credit Entries to Receivers
Subject to its right to return or reject entries in accordance with these Rules, each RB must make the amount of each credit entry received from the BEFTN available to the Receiver for withdrawal or cash withdrawal no later than the Settlement Date of the entry.

4.3.2 Time of Debiting of Entries
A RB must not debit the amount of any entry to a Receiver’s account prior to the Settlement Date of the entry, even if the effective entry date of the entry is different from the Settlement Date of the entry.
4.3.3 Provision of PaymentRelated Information to Receiver
Upon the request of the Receiver, a RB must provide to its Receiver all Payment‐Related Information contained within any Addenda Records transmitted with the entries (especially CTX entry). The RB must provide this information to its Receiver on the Settlement Date of the entry.
4.3.4 Crediting of Originators’ Accounts by Receiver
A Receiver must credit the Originator with the amount of an entry credited to the Receiver’s account as of the Settlement Date. The Receiver shall have a reasonable period of time after the entry is credited to the Receiver’s account to post the amount of the credit to the Originator’s account or return the entry to the RB. For purposes of this section, a Receiver shall be considered to act within a reasonable period of time if the Receiver posts the credit or returns the entry no later than the time at which the Receiver would usually complete the process of posting credits resulting from payments received to its customers’ accounts or returning these payments. A Receiver that returns an entry according to the requirements of this subsection 4.4.4 is not considered to have accepted the entry.
4.3.5 Rights of Receiver Upon Unauthorized Debit to Its Account
A Receiver or other person whose account is debited by an entry which is, in whole or in
part, not authorized by such person shall have rights, including the right to have the account
re‐credited as provided by law or agreement. Except as provided for in subsection 7.6.7 (Waiver of Right to Re‐credit), these Rules shall not provide for or restrict any such rights.
4.3.6 Reliance on Standard Entry Class Codes
A RB may consider an entry containing a Standard Entry Class Code specified in Appendix Two (BEFTN Record Format Specifications) as complying with the requirements of these Rules for that type of entry.
4.3.7 Reimbursement of RB
A credit entry given to the Receiver by the RB as provided in subsection 4.4.1 (Availability of Credit Entries to Receivers) is provisional until the RB has received final settlement through Bangladesh Bank. If such settlement of payment is not received, the RB is entitled to a refund from the Receiver of the amount credited, and the Originator is considered not to have paid the Receiver the amount of the entry.
SECTION 4.4 Periodic Statements
A RB must send or make available to each of its Receivers information concerning each credit and debit entry to a Consumer Account of the Receiver in accordance with Appendix Four (Minimum Description Standards).

SECTION 4.5 Notice to Receiver
A RB is not required to notify a Receiver of receipt of an entry to its account unless otherwise provided for in an agreement between the RB and Receiver or required by government statute or regulation which cannot be varied by these Rules or by agreement of the parties.
SECTION 4.6 Release of Information
Each RB agrees that BEFTN Authority may release information to any concerned department of Bangladesh Bank regarding EFT return entries transmitted to or by the RB.
SECTION 4.7 Liability of RB for Benefit Payments
4.7.1 Liability of RB
If a Receiver has died and the Receiver’s right to receive one or more pension, annuity, or other benefit payments by credit entry has terminated before the receipt by the RB of one or more credit entries to the Receiver’s account representing those payments, the RB may be liable to the Originator for the amount of those entries credited to the Receiver’s account if neither the Receiver’s estate nor any other holder of the account is entitled to the payments. The liability a RB would incur under this subsection 4.7.1 is limited as provided in this section 4.7.
4.7.2 Amount of RB Liability
A RB’s liability under this section 4.7 shall be the lesser of (1) the amount of any payments to which the Receiver was not entitled, or (2) the amount in the Receiver’s account at the time the RB receives (i) a reclamation entry initiated by the OB pursuant to section 2.6 (Reclamation Entries) and not returned by the RB or (ii) a written demand for payment from the OB or Originator pursuant to subsections 4.7.3 (Demand for Payment) and 4.7.4 (Timing) and has a reasonable opportunity to act upon such demand. A claim or demand by an Originator (or OB on the Originator’s behalf) will be subordinate to claims or potential claims of The Government of the People's Republic of Bangladesh. The Originator must reimburse the RB for any payments made to the Originator pursuant to this section 4.7 that are subject to a subsequent claim of The Government of the People's Republic of Bangladesh.
4.7.3 Demand for Payment
A RB will have no liability under this section 4.7 unless and until it receives (1) a reclamation entry initiated by the OB pursuant to section 2.6 (Reclamation Entries) and not returned by the RB, or (2) a written demand for payment from the OB or Originator. The reclamation entry or written demand for payment must identify the name of the Receiver, the account at the RB credited on the Receiver’s behalf, and the exact amount and approximate date of initiation for each entry involved.
4.7.4 Timing
A reclamation entry must be originated or a written demand for payment sent within five Banking days after the Originator receives notice of the death of the Receiver. If a reclamation entry is returned by the RB, the Originator may make a written demand for payment within 15 Banking days after it receives the returned reclamation entry.
4.7.5 Alteration by Agreement
Notwithstanding any other provision of these Rules, the liability provisions contained within this section 4.7 may be altered, amended, or superseded by a written agreement between

the Originator and RB only if the agreement clearly and conspicuously states on its face that it is a master agreement, that both the Originator and RB consider it to be a master agreement, and that it is applicable to all payments subject to this section 4.7 sent by the Originator to the RB for the benefit of all Receivers having accounts at the RB. No provision of these Rules prevents a RB from expressly agreeing in a master agreement that the liability provisions of this section 4.7 may be altered, amended, or superseded on a Receiver‐by‐ Receiver basis.

ARTICLE FIVE
RETURN, ADJUSTMENT, CORRECTION, AND ACKNOWLEDGMENT OF ENTRIES AND ENTRY INFORMATION
SECTION 5.1 Return of Entries
5.1.1 Right to Return Entries
Except as otherwise provided for in subsection 5.1.3 (Restrictions on Right to Return), a RB may return an entry for any reason.
5.1.2 Requirements of Returns
Each return entry must comply with the requirements of Appendix Five (Return Entries). Except as otherwise provided in this section 5.1, subsection 5.3.2 (OB and Originator Action on Notification of Change), each return entry must be received by the BEFTN by its deposit deadline for the return entry to be made available to the OB no later than the opening of business on the second Banking day following the Settlement Date of the original entry. For purposes of the preceding sentence, the term second Banking day shall refer to the second Banking day of the BEFTN, and the term Settlement Date of the original entry shall refer to the Settlement Date of the original entry that is being returned. A return entry relating to a credit entry must be transmitted by the RB to the BEFTN if the Receiver of the entry does not have an account with the RB, the Receiver’s account has been closed, or the RB is not permitted by law to receive credits for the Receiver’s account. A return entry which is rejected by the BEFTN Authority does not meet or extend the deadline contained in this
section 5.1.
5.1.3 Restrictions on Right to Return
A RB may not return an entry because it is a credit, debit, or zero Taka entry or is a particular type of credit, debit, or zero Taka entry. A RB may, however, return any debit entry or any entry received that concerns any account that is not a “transaction account” maintained with that RB.
5.1.4 Credit Entries Returned by Receiver
A RB may return any credit entry that is returned to it by a Receiver as provided for in subsection 4.4.4 (Crediting of Originators’ Accounts by Receiver). The RB must transmit the return entry to the BEFTN by midnight of the Banking day following the Banking day of receipt by the RB from the Receiver.
5.1.5 Return of Unposted Credit Entries
A RB must return all credit entries that are not credited or otherwise made available to its Receivers’ accounts by midnight of the Banking day following the Settlement Date.
5.1.6 Acceptance of Return Entries by OB
An OB must accept return entries complying with Appendix Five (Return Entries) and transmitted by the RB within the time limits established by these Rules.

5.1.7 Reinitiation of Return Entries by OB
An entry that has been returned may not be reinitiated unless (1) the entry has been returned for insufficient or uncollected funds; (2) the entry has been returned for stopped payment and re‐initiation has been authorized by the Receiver; or (3) the OB has taken corrective action to remedy the reason for the return. An entry that has been returned for insufficient or uncollected funds may be reinitiated no more than two times following the return of the original entry.
SECTION 5.2 Dishonour of Return Entries
5.2.1 Dishonour of Return by OB
An OB may dishonour a return entry (1) if it can substantiate that the RB failed to return the entry within the time limits established by these Rules, thus causing either the OB or Originator to suffer a loss, or (2) if the return entry contains incorrect information, does not include all information required by Appendix Five (Return Entries), or otherwise fails to comply with the requirements of Appendix Five. To dishonour a return entry, the OB must transmit a dishonoured return entry complying with Appendix Five to BEFTN within five Banking days after the Settlement Date of the return entry.
5.2.2 Contesting of Dishonoured Returns by RB
A RB may dispute a dishonoured return entry based on an untimely receipt of the dishonoured return, if the return entry was, in fact, returned within the time limits established by these Rules, the RB can initiate a contested dishonoured return entry. A contested dishonoured return entry must comply with the requirements of Appendix Five (Return Entries) and must be transmitted to the BEFTN within two Banking days after the Settlement Date of the dishonoured return entry. The OB must accept a contested dishonoured return entry transmitted by the RB and complying with this section 5.2.
5.2.3 Contesting a Contested Dishonoured Return
An OB may not contest a contested dishonoured return received from a RB by reinitiating the entry. Any further action concerning a contested dishonoured return must be pursued outside of the BEFTN operating rules.
5.2.4 Corrected Returns
A RB receiving a dishonoured return entry based on a return entry containing incorrect information, failing to contain all information required by Appendix Five (Return Entries), or otherwise failing to comply with the requirements of Appendix Five may transmit a corrected return entry to the BEFTN within two Banking days of the Settlement Date of the dishonoured return entry. The corrected return entry must comply with the requirements of
Appendix Five and must include the dishonoured return information received from the OB.
The OB must accept a corrected return entry transmitted by a RB in accordance with this subsection 5.2.3.
SECTION 5.3 Notification of Change
5.3.1 Notifications of Change; RB Warranties and Indemnity
A RB may transmit a notification of change (NOC) to the BEFTN provided that (1) the notification of change complies with the requirements of Appendix Six (Notification of Change), and (2) except for NOCs due to merger, acquisition, or other similar events, the NOC is transmitted within two Banking days of the Settlement Date of the entry to which the

NOC relates. Each RB that transmits an NOC or corrected NOC as provided for in subsection
5.4.2 (RB Action on Refused Notification of Change) warrants to each OB and the BEFTN
AUTHORITY that (1) the information contained within the NOC or corrected NOC is correct, and (2) if the change relates to the Receiver’s account number, the Receiver has authorized the change, if authorization is required, and the RB has complied with any applicable legal requirements for such authorization. The RB’s warranty supersedes and renders inoperative any similar warranty (but not any other warranty) of the OB contained within subsection
2.2.1 (Warranties). Any RB that breaches the warranties of this subsection 5.3.1 shall
indemnify each OB and the BEFTN AUTHORITY from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting directly or indirectly from the breach of warranty.
5.3.2 OB and Originator Action on Notification of Change
Unless otherwise provided for in this Article Five, an OB must accept NOCs and corrected NOCs that comply with the requirements of Appendix Six (Notification of Change) and that are transmitted by the RB within the time limits established by these Rules. Each OB must, at a minimum, provide to the Originator information relating to NOCs and corrected NOCs in accordance with the requirements of Appendix Six. The Originator must make the changes specified in the NOC or corrected NOC within six Banking days of receipt of the NOC information or prior to initiating another entry to the Receiver’s account, whichever is later.
SECTION 5.4 Refused Notification of Change
5.4.1 OB Right to Refuse Notification of Change Entries
An OB may refuse a NOC or corrected NOC if (1) the NOC or corrected NOC contains incorrect information, (2) the NOC or corrected NOC does not contain all information required by Appendix Six (Notification of Change), or (3) the NOC otherwise fails to comply with Appendix Six. To refuse an NOC or corrected NOC, the OB must transmit an automated refused notification of change complying with Appendix Six to the BEFTN within fifteen days of receipt of the NOC or corrected NOC.
5.4.2 RB Action on Refused Notification of Change
A RB may transmit a corrected NOC complying with Appendix Six (Notification of Change) to the BEFTN within five Banking days after the Settlement Date of the refused NOC.

ARTICLE SIX
SETTLEMENT AND ACCOUNTABILITY
SECTION 6.1 Maintenance of Central Bank Account
Each Participating Bank must maintain an account with Bangladesh Bank.
SECTION 6.2 Settlement
Settlement among Participating Banks for entries, adjustment entries, and return entries transmitted in accordance with these Rules will be effected by the crediting or debiting of the Bangladesh Bank accounts of Participating Banks referred to in section 6.1 (Maintenance of Central Bank Accounts).
SECTION 6.3 Effect of Settlement
Settlement of entries does not preclude a Participating Bank from pursuing any available legal rights or remedies concerning any entry, adjustment entry, or return entry, including without limitation any right or remedy arising out of a return entry or adjustment entry, transmitted after the time limits established by these Rules.
SECTION 6.4 Accountability for Entries
Each RB is accountable for the amount of all debit entries received that are not returned in accordance with these Rules, except as provided for in subsection 5.3.2 (OB and Originator Action on Notification of Change). The RB’s accountability under this section is not affected by the failure of the OB to comply with the provisions of section 5.2 (Dishonour of Return Entries).
SECTION 6.5 Effect of RB Closing on Time of Settlement
If the scheduled Settlement Date of a debit entry is not a Banking day for the RB but is a day on which the Central Bank described in section 6.1 (Maintenance of Accounts at the Central Bank) is open, settlement will occur on the scheduled date, unless the RB has previously advised the Bangladesh Bank that settlement for the entry should be deferred until the next Banking day. If the RB has provided such notice to the Bangladesh Bank, settlement for the debit entry will occur on the next Banking day, and the RB shall pay the float charge assessed by the Bangladesh Bank.
SECTION 6.6 Effect of OB Closing on Time of Settlement
If the scheduled Settlement Date for a credit entry is not a Banking day for the OB but is a day on which the applicable office of the Central Bank described in section 6.1 (Maintenance of Accounts at the Central Bank) is open, settlement will occur on the scheduled date.

ARTICLE SEVEN
RECALL, STOP PAYMENT, RECREDIT, AND ADJUSTMENT
SECTION 7.1 Recall by OB or Originator
Except as allowed by sections 2.4 (Reversing Files), 2.5 (Reversing Entries), and 2.6 (Reclamation Entries), neither an Originator nor an OB has the right to recall an entry or file, to require the return of or adjustment to an entry, or to stop the payment or posting of an entry, once the entry or file has been received by the BEFTN.
SECTION 7.2 OB Request for Return
An OB may, orally or in writing, request a RB to return or adjust an erroneous entry initiated by the OB. For purposes of this section 7.2, an erroneous entry is an entry (1) that is a duplicate of an entry previously initiated by the Originator or OB, (2) that orders payment to or from a Receiver not intended to be credited or debited by the Originator, or (3) that orders payment in an amount different than was intended by the Originator. The RB may, but is not obligated to, comply with such a request. The OB making such a request indemnifies the RB from and against any and all claim, demand, loss, liability or expense, including legal fees and costs, resulting directly or indirectly from compliance by the RB with such request.
SECTION 7.3 OB Agrees to Accept a Corporate Debit Return
If a RB receives written notification from a Receiver after the time for return has expired (see Article Five, section 5.1 ‐ Return of Entries) that a Corporate debit entry to the Receiver’s account was, in whole or in part, not authorized by the Receiver, the RB may transmit a permissible return entry to the OB, provided that the OB agrees, either verbally or in writing, to accept the late return entry. The permissible return entry must be in the amount of the debit entry and must comply with the requirements of Article Five, section 5.1 and Appendix Five (Return Entries).
SECTION 7.4 Stop Payment Affecting Consumer Accounts
A Receiver may stop the payment of a debit entry initiated or to be initiated to a Consumer Account of the Receiver by providing either verbal or written notification to the RB at least three Banking days before the scheduled date of the transfer. A RB may honour a stop payment order received within the three‐Banking‐day limit prescribed above, and, if it honours such a request, the RB has no resultant liability or responsibility to any Originator, OB, or other person having any interest in the entry. The RB may require that written confirmation of a verbal stop payment order be made within 14 days of a verbal stop payment order, provided that the RB notifies the Receiver of this requirement and provides an address to which the written confirmation should be sent at the time the verbal order is provided. If the RB requires written confirmation, the verbal stop payment order will cease to be binding after 14 days. A Receiver may withdraw a stop payment order by providing written notice to the RB. A stop payment order will remain in effect (1) for six months from the date of the stop payment order, (2) until payment of the debit entry has been stopped, or (3) until the Receiver withdraws the stop payment order, whichever occurs earliest.
SECTION 7.5 Stop Payment Affecting NonConsumer Accounts
A Receiver may order its RB to stop the payment of any debit entry initiated or to be initiated to a non‐Consumer Account of the Receiver. The stop payment order must be provided to the RB at such time and in such manner as to allow the RB a reasonable opportunity to act upon the stop payment order prior to acting on the debit entry. The RB is obligated to comply with a verbal stop payment order only for a period of fourteen calendar days unless the order is confirmed in writing within that

14‐day period. A written stop payment order is effective for six months unless it is renewed in writing.
SECTION 7.6 Receiver’s Right to Recredit
7.6.1 Receiver’s Right to Recredit
A RB must promptly credit the amount of a debit entry to a Consumer Account of a Receiver if (1) the Receiver sends or delivers to the RB a written statement as described in subsection
7.6.4 (Receiver’s Written Statement) that the debit entry was not authorized by the
Receiver, and (2) this written statement is sent or delivered to the RB within 180 calendar days from the date the RB sends or makes available to the Receiver information relating to the debit entry in accordance with section 4.5 (Periodic Statements).
7.6.2 Receiver’s Written Statement
For all consumer entries, a Receiver must sign or similarly authenticate a written statement, in the form required by the RB, that the debit entry for which the Receiver is seeking re‐ credit under this section 7.6 was not authorized by the Receiver.
7.6.3 Unauthorized Debit Entry
For purposes of this section (7.6), a debit entry was not authorized by the Receiver if (1) the authorization requirements of subsection 2.1.2 (Receiver Authorization and Agreement) have not been met; (2) the debit entry was initiated in an amount greater than that authorized by the Receiver; or (3) the debit entry was initiated for settlement earlier than authorized by the Receiver. An unauthorized debit entry does not include a debit entry initiated with fraudulent intent by the Receiver or any person acting in concert with the Receiver.
7.6.4 Waiver of Right to Recredit
An Originator may request a Receiver to waive the Receiver’s rights under subsection 4.4.5 (Rights of Receiver Upon Unauthorized Debit to Its Account) with respect to one or more specific debit entries initiated to the Receiver’s account. This waiver must (1) be in writing in a document entitled “Waiver with respect to pre‐arranged debit”, (2) specify the amount of each entry to which the waiver applies, (3) specify the approximate date on which each entry was initiated by the Originator, (4) specify the Originator number designated in each entry, and (5) specifically state in substance that the Receiver waives any right to have a designated RB credit the amount of the entry or entries to the Receiver’s account due to error, unless the error was made by the RB. Except for waivers complying with the requirements of this subsection 7.6.4, no waiver by a Receiver of rights provided in subsection 4.4.5 is effective for any purpose.
7.6.5 Effect of Execution of Waiver
If a waiver complying with the requirements of subsection 7.6.4 (Waiver of Right to Re‐ credit) has been signed by the Receiver and received by the RB in sufficient time and in such manner as to afford the RB a reasonable opportunity to act upon it, subsections 7.6.1 (Receiver’s Right to Re‐credit), 7.6.2 (Receiver’s Written Statement), and section 7.7 (Adjustment Entries) shall not apply to the entry or entries to which the waiver relates. If an Originator transmits such a waiver, with a copy, to a RB, the RB, upon written request of the Originator, must acknowledge receipt on the copy of the waiver and promptly deliver or send that copy to the Originator.

7.6.6 Recredit Right Not Exclusive
The rights provided to the Receiver under this section 7.6 are in addition to any rights provided under other applicable law.
SECTION 7.7 Adjustment Entries
7.7.1 RB’s Right to Adjustment
For all consumer entries, a RB receiving the written statement described in subsection 7.6.2 (Receiver’s Written Statement) may transmit an adjustment entry to its BEFTN in the amount of the unauthorized entry referred to in the written statement, provided that (1) no error was made by the RB in the debiting of the entry to the Receiver’s account, (2) the written statement described in subsection 7.6.2 was sent or delivered to the RB, and (3) the RB transmitted the adjustment entry to the BEFTN by its deposit deadline for the adjustment entry to be made available to the OB no later than the opening of business on the Banking day following the one hundred eightieth calendar day following the Settlement Date of the original entry. The adjustment entry must comply with the requirements of section 5.1 (Return of Entries) and Appendix Five (Return Entries). A RB may consider a written statement as timely if, in its reasonable judgment, the written statement appears to have been sent within the time limits described above.
7.7.2 Warranty of RB
Each RB transmitting an adjustment entry pursuant to subsection 7.7.1 (RB’s Right to Adjustment), warrants to each OB and the BEFTN prior to initiating the adjustment entry, the RB obtained from the Receiver a written statement complying with section 7.6 (Receiver’s Right to Recredit). Each RB breaching this warranty shall indemnify every OB and the BEFTN from and against any and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting directly or indirectly from the breach of such warranty.
7.7.3 Copy of Written Statement
Each RB initiating an adjustment entry pursuant to subsection 7.7.1 (RB’s Right to Adjustment) will provide a copy of the written statement obtained from the Receiver in accordance with section 7.6 (Receiver’s Right to Recredit), provided such request is received by the RB within one year of the date of the initiation of the adjustment entry.
7.7.4 Acceptance of Adjustment Entries by OB
Each OB must accept adjustment entries transmitted to it in accordance with these Rules.

ARTICLE EIGHT
OBLIGATIONS OF THE BEFTN AUTHORITY
SECTION 8.1 Processing Obligation
The BEFTN Authority must, in accordance with Appendix Two (BEFTN Record Format Specifications):
(1) promptly process entries and entry data, insert the appropriate Settlement Date, and reject batches and files in accordance with section 8.3 (Return and Rejection by BEFTN), (2) transmit or make available entries and entry data to Participating Banks in accordance with agreed upon processing and delivery schedules, (3) remake any file rejected by a RB, (4) total the debit and credit activity received from and transmitted to Participating Banks during each Banking day, and (5) calculate and report the settlement amounts for each day for all entries processed under these Rules.
SECTION 8.2 Return and Rejection by BEFTN
If an entry or entry data received for processing does not meet the acceptance criteria set forth in
Appendix Two (BEFTN Record Format Specifications), Appendix Five (Return Entries), or Appendix Six
(Notification of Change), the BEFTN must in accordance with those Appendices either return the entry or entry data to the appropriate OB or reject the entire batch or file containing the entry by notifying the appropriate OB.
SECTION 8.3 Originator Status Code Review
The BEFTN must review each batch of entries it receives to ensure that the appropriate status code pertaining to the Originator (the “Originator Status Code”) is included in accordance with Appendix Two (BEFTN Record Format Specifications). If a batch of entries contains an incorrect Originator Status Code or contains no Originator Status Code, the BEFTN must either reject the batch or insert the correct Originator Status Code.
SECTION 8.4 Optional Services
The BEFTN may provide optional services. The use of the optional services must not inconvenience or adversely affect the rights of Participating Banks that do not use optional services.
SECTION 8.5 NonSettled Entries
If a Participating Bank is unable to meet its settlement obligations under the settlement rules established by the Bangladesh Bank for entries it has originated or received (“non‐settled entries”), the BEFTN must return or reverse the non‐settled entries in accordance with sections 8.6 (Entries Originated to a RB that Cannot Settle) and 8.7 (Entries Received from an OB that Cannot Settle). The BEFTN is responsible for establishing the definition of non‐settled entries and the procedures under which settlement balances are to be adjusted within its own settlement rules.
SECTION 8.6 Entries Originated to a RB that Cannot Settle
The BEFTN must create a return entry complying with the requirements of Appendix Five (Return Entries) for each non‐settled entry and transmit that non‐settled entry to the OB. An OB that receives a return entry complying with the requirements of this section 8.6 must accept and may not dishonour that entry. The OB may not reinitiate a non‐settled entry.

SECTION 8.7 Entries Received from an OB that Cannot Settle
The BEFTN Authority must create a reversing entry complying with the requirements of Appendix Two (BEFTN Record Format Specifications) for each non‐settled entry and transmit that non‐settled entry to the RB. A RB that receives such a reversing entry complying with the requirements of this
section 8.7 must accept and may not return that reversing entry.
SECTION 8.8 Record of Entries
The BEFTN Authority must retain a record of all entries, return entries, and adjustment entries (all referred to in this section as “entries”) received or transmitted by it for twelve years from the date of receipt or transmittal of the entry. The BEFTN must provide a printout or access to the archive of the information relating to a particular entry if requested to do so by the Participating Bank that originated, transmitted, or received the entry.

ARTICLE NINE
RESPONSIBILITIES OF BANGLADESH BANK AND BEFTN PARTICIPANTS
SECTION 9.1 General
This Article describes and governs the clearing and settlement of Bangladesh Electronic Funds Transfer Network (BEFTN) credit and debit items. The BEFTN Rules are binding on a sending bank that sends items to the Bangladesh Bank, a receiving bank that receives items from the Bangladesh Bank, an account holder that has agreed to settle for items under this Article. Any EFT item that is sent to the Bangladesh Bank (BEFTN) for processing and settlement is subject to the provisions of this Article. The Bangladesh Bank processes such items as a BEFTN operator and does not collect, present, or return such items as a “collecting” or “returning” bank unless Bangladesh Bank choose to take part as a participants (OB/RB) for it’s own or for the government’s payment processing purpose.
SECTION 9.2 Sending Credit and Debit Items
9.2.1. A sending bank that maintains or uses a settlement account at the Bangladesh Bank
may send an item to the Bangladesh Bank, provided the receiving bank maintains or uses a settlement account for BEFTN items at the Bangladesh Bank.
9.2.2. An item must be in the media the Bangladesh Bank prescribes and in the format
prescribed by the applicable BEFTN rules.
9.2.3. A sending bank may with the prior approval of Bangladesh Bank designate a sending
point as its agent to send items to the Bangladesh Bank. It is the sending bank’s responsibility to ensure that its agent complies with the sending bank’s obligations under these Rules.
9.2.4. The sending bank agrees to indemnify, defend, and hold the Bangladesh Bank
harmless against any claim, loss, cost, or expense resulting from (i) the acts or omissions of the sending bank’s agent; (ii) the Bangladesh Bank’s acts or omissions in carrying out the instructions of such agent within the scope of the agency appointment; or (iii) the Sub member access arrangement including but not limited to attorney’s fees and expenses of litigation, except for any claim, loss, cost, or expense arising solely out of the Bangladesh Bank’s failure to exercise ordinary care or to act in good faith.
SECTION 9.3 Security Procedures
9.3.1. The security procedures the Bangladesh Bank offers to verify the authenticity of the
source of an item by following the procedures outlined in the Bangladesh Bank Participating Bank Module specifications.
9.3.2. All BEFTN files originated by the sending bank will be digitally signed and encrypted by
the presenting bank before transmission to BEFTN and all outgoing BEFTN files will be digitally signed and encrypted by BEFTN before being transmitted to the receiving bank.
9.3.3. Each sending bank and receiving bank shall prevent any disclosure of any aspects of
the security procedures offered by the Bangladesh Bank, as provided in Bangladesh Bank’s Participating Bank Module specifications. The sending bank or the receiving bank shall notify the Bangladesh Bank immediately if the confidentiality of these security procedures is compromised, and shall act to prevent the security procedure from being further compromised.

SECTION 9.4 Sending Bank’s Agreements
By sending an item to the Bangladesh Bank, the sending bank:
(a) agrees to comply with the applicable BEFTN rules and agrees that those rules govern the relationships among the sending bank, the receiving bank and other parties interested in the item and covered by those rules; (b) authorizes the Bangladesh Bank to process the item in accordance with these Rules. (c) agrees that the Bangladesh Bank processes the items as the BEFTN operator and does not collect, present, or return the items as a “collecting” or “returning” bank., (d) authorizes the Bangladesh Bank holding the sending bank’s settlement account to debit the amount of a credit item, or credit the amount of a debit item, to the sending bank’s settlement account on the settlement date; and (e) agrees to indemnify the Bangladesh Bank processing or settling for the item for any loss or expense (including attorneys fees and expenses of litigation) incurred by the Bangladesh Bank as a result of any action taken with respect to the item by the Bangladesh Bank.
SECTION 9.5 Processing of Items
9.5.1. The Bangladesh Bank processes items in accordance with the applicable BEFTN rules.
The Bangladesh Bank may reject, or may impose conditions to it’s processing of, any item for any reason. The Bangladesh Bank will not act on instructions in an item other than information required by format specifications in applicable BEFTN rules. If the Bangladesh Bank notifies a sending bank of the receipt of a suspected duplicate file or any other problem, the Bangladesh Bank will not process the file without approval by the sending bank or its agent. Except as expressly provided in these Rules the Bangladesh Bank does not have or assume any responsibility for a sending or receiving bank’s compliance with applicable BEFTN rules. The Bangladesh Bank may record by audio recording device any telephone call relating to an item.
9.5.2. The Bangladesh Bank provides an acknowledgment to the sending bank that the
Bangladesh Bank has received BEFTN files by electronic transmission and has performed limited processing of the files, as provided in applicable BEFTN rules. An acknowledgment does not mean that the Bangladesh Bank has accepted, and will not reject, the items contained in the files. The sending bank is responsible for verifying the information in the acknowledgment and notifying the Bangladesh Bank immediately of any discrepancy, and for notifying the Bangladesh Bank promptly of non‐receipt of an acknowledgment.
9.5.3. A sending bank must designate the receiving bank for an item by routing number. The
Bangladesh Bank is not responsible for the accuracy of a routing number contained in and/or verbally supplied from a publication, list or automated file issued by an organization other than Bangladesh Bank. The Bangladesh Bank may process an item on the basis of a routing number of a receiving bank appearing in any form on the item when received. The Bangladesh Bank is not responsible for any loss or delay resulting from acting on the number, whether or not the number is consistent with any other designation of the receiving bank on the item, if the Bangladesh Bank does not know of the inconsistency in designation.

SECTION 9.6 Delivery of Items
9.6.1. By prior arrangement with a receiving bank, the Bangladesh Bank sends items by
electronic means to the receiving bank, or with the prior approval of Bangladesh Bank to a receiving point designated by the receiving bank. Alternatively, by prior agreement with a receiving bank the Bangladesh Bank may deliver items by making them available on the BEFTN system for the receiving bank or its agent to retrieve. The Bangladesh Bank has delivered such items when it has placed the items on the Bangladesh Bank storage device and made the items available for the receiving bank or its agent to retrieve. In emergency circumstances, the Bangladesh Bank may send items as arranged with the receiving bank. Items are considered received by a receiving bank in accordance with applicable BEFTN rules, except as provided in paragraph 9.6.2. A receiving bank should promptly advise the Bangladesh Bank if it does not receive items by the expected date.
9.6.2. A receiving bank must manage its electronic connection so as to permit it to receive
items in a timely manner throughout the day. A receiving bank that does not receive items in a timely manner because it fails to so manage its electronic connection, or because of emergency circumstances beyond the control of the Bangladesh Bank, is required to settle for the items with the Bangladesh Bank on the settlement date, but is not considered to receive the items for purposes of the deadline for return.
9.6.3. A receiving bank may designate a receiving point as its agent to receive items from the
Bangladesh Bank. It is the receiving bank’s responsibility to ensure that its agent complies with the receiving bank’s obligations under these Rules (a) By receiving items from the Bangladesh Bank at a receiving point that is owned or operated by an entity other than the receiving bank itself, a receiving bank designates the entity that operates the receiving point as its agent for accessing the BEFTN items., authorizes the Bangladesh Bank to act on the instructions of such agent with respect to the handling of items received from the Bangladesh Bank by the agent on behalf of the receiving bank. (b) The receiving bank’s agent’s access to the Bangladesh Bank’s electronic systems is governed by the Bangladesh Bank Participating Bank Module specifications, as amended from time to time (c) The receiving bank authorizes the Bangladesh Bank to act upon items, information, and instructions sent to the Bangladesh Bank by the receiving bank’s agent that the agent identifies as having been authorized by the receiving bank. (d) The receiving bank agrees that:
(i) its agent will be granted credentials authorizing such agent to access the Bangladesh Bank systems for the purposes of the BEFTN service; (ii) its agent will use those credentials to act on behalf of the receiving bank; and (iii) its agent will use the same credentials to access the Bangladesh Bank’s BEFTN systems on behalf of other banks that use the same agent to access the Bangladesh Bank’s electronic systems. It is the responsibility of the receiving bank and its agent to establish controls sufficient to assure that the agent properly segregates the items, information, and instructions of a receiving bank from any items, information, or instructions of other receiving banks. The Bangladesh Bank is not required to take, and will not take, any measures to assure that the receiving bank’s work is properly identified or segregated by the agent.

(e) The receiving bank agrees to be bound by the agent’s acts or omissions with respect to items that are handled by the Bangladesh Bank pursuant to these Rules. (f) The receiving bank authorizes the Bangladesh Bank to settle for items sent to or received from the Bangladesh Bank by the receiving bank’s agent, and to obtain from the receiving bank payment as provided in these Rules for any fees owed to the Bangladesh Bank in connection with items sent to the Bangladesh Bank or received from the Bangladesh Bank by the receiving bank’s agent. (g) The receiving bank agrees that the Bangladesh Bank may send items to the receiving bank by delivering or transmitting such items to the receiving bank’s agent. (h) The Bangladesh Bank may rely on the agency appointment until it is revoked in writing and the Bangladesh Bank has had a reasonable amount of time to respond to such revocation. (i) The receiving bank is responsible for any obligations regarding settlement of items that exist at the time of any termination of the agency appointment and these shall survive the termination of the agency appointment. (j) The receiving bank agrees to indemnify, defend, and hold the Bangladesh Bank harmless against any claim, loss, cost, or expense resulting from (i) the acts or omissions of the receiving bank’s agent; (ii) the Bangladesh Bank’s acts or omissions in carrying out the instructions of such agent within the scope of the agency appointment; or (iii) the Sub member access arrangement including but not limited to attorney’s fees and expenses of litigation, except for any claim, loss, cost, or expense arising solely out of the Bangladesh Bank’s failure to exercise ordinary care or to act in good faith.
SECTION 9.7 Time Schedules, Settlement Dates and Extension of Time Limits
9.7.1 The BEFTN items processing schedule as published from time to time will show the
banking days and the deadlines for the Bangladesh Bank to receive credit and debit items of various classes for immediate or next day settlement. The time schedule also shows the effective date window for classes of items and provisions for settlement for various effective dates.
9.7.2 The Bangladesh Bank processes items in accordance with their processing schedules,
and sends them to the receiving bank on or before the settlement date. If, because of circumstances beyond the Bangladesh Bank’s control, it is delayed beyond the applicable time limit in acting on an item, the time for acting is extended for the time necessary to complete the action, provided the Bangladesh Bank exercises such diligence as the circumstances require.
SECTION 9.8 Designation of Settlement Account
9.8.1 Prior to sending an item to (or receiving an item from) the Bangladesh Bank, a sending
bank (and a receiving bank) must designate a settlement account(s) on the Bangladesh Bank’s books, and identify the transactions to be settled through the account(s). If the bank designates a correspondent bank’s account, the correspondent bank must agree to that designation. A sending bank or receiving bank remains responsible under these Rules for all transactions, notwithstanding that it has designated a settlement account, including a settlement account maintained by a correspondent bank. The Bangladesh Bank may at its discretion, recover the unpaid balance of the sending or receiving bank’s obligation with

respect to an item from the sending or receiving bank, respectively, without prior notice or demand.
9.8.2 The Bangladesh Bank may charge against a sending bank’s or a receiving bank’s
designated settlement account the amount of the bank’s BEFTN transactions, unless the Bangladesh Bank and the sending or receiving bank agree to other arrangements for settlement.
9.8.3 By designating a settlement account, a bank (and its correspondent bank, if any, that
maintains the designated settlement account) authorizes the Bangladesh Bank; (1) to debit the designated account on the settlement date the amount of credit items sent by the bank to the Bangladesh Bank, the amount of debit items sent to the bank by the Bangladesh Bank; (2) to credit to the designated account on the settlement date the amount of debit items sent by the bank to the Bangladesh Bank, the amount of credit items sent to the bank by the Bangladesh Bank; and (3) to debit and credit to the designated settlement account the amount of other transactions (including fees, unless otherwise agreed) with respect to BEFTN Items. The bank (and its correspondent bank, if any, that maintains the designated settlement account) agrees to maintain to its credit in the designated settlement account, consistent with paragraph 10 of these Rules a balance of actually and finally collected funds sufficient to cover charges under these Rules and all other charges to its account. The Bangladesh Bank assumes no responsibility for any obligations or rights of a bank with respect to its correspondent bank, if any (or of an intermediary correspondent that is not an account holder, if any, with respect to its correspondent account holder).
9.8.4 By designating a settlement account, and in consideration of the processing and
settlement by the Bangladesh Bank of items sent to and/or received by the bank and other sending and receiving banks, the bank (and its correspondent bank, if any, that maintains the designated settlement account) agrees to the applicable BEFTN rules, as amended from time to time, for the benefit of all parties interested in the items.
9.8.5 A settlement designation supersedes all prior inconsistent designations with respect to
items. The sending or receiving bank may terminate a settlement designation by written notice to the Bangladesh Bank and the Bangladesh Bank may terminate a settlement designation by written notice to the bank.
SECTION 9.9 Settlement
9.9.1 A sending or receiving bank’s settlement obligation is owed to the Bangladesh Bank.
9.9.2 On the settlement date, the Bangladesh Bank debits (or credits) that account in the
amount of a credit (or debit) item.
9.9.3 To secure any obligation, now existing or arising in the future, in connection with a
BEFTN item by a sending or receiving bank (or by a correspondent bank whose account a sending or receiving bank uses for settlement) to the Bangladesh Bank, the bank grants to the Bangladesh Bank all the bank’s right, title, and interest in property, whether now owned or hereafter acquired, in the possession or control of, or maintained with, the Bangladesh Bank including but not limited to the bank’s deposit account, items in the process of collection and their proceeds, and any investment property (including securities, security entitlements, and security accounts), but excluding any investment property which the bank may not encumber under applicable law. This security interest is in addition to any other security interest granted to the Bangladesh Bank by the bank under regulation or agreement. The Bangladesh Bank may take any action authorized by law to recover the amount owed to it by the bank, including but not limited to the exercise of setoff without

demand or notice and even if the obligations are contingent or un‐matured, the realization on any available collateral, and the exercise of any rights it may have as a creditor under applicable law.
9.9.4 If the Bangladesh Bank, in its sole discretion, determines that there may not be
sufficient funds in the account at the settlement time on the settlement date to cover a debit for a credit item or for a received debit item, the Bangladesh Bank may cease processing the item and may refuse to settle for it. The Bangladesh Bank may also cease processing and refuse to settle for an item if they receive notice of the suspension or closing of the sending bank or receiving bank prior to the time settlement is final under these Rules. If the Bangladesh Bank ceases processing or refuses to settle for an item, they will notify the sending bank and a receiving bank to which the item has been sent (or a correspondent bank whose account a bank uses for settlement) as soon as possible.
SECTION 9.10 Availability of Credit
9.10.1 Credit given for a debit item by the Bangladesh Bank is available for use and may
qualify as reserve on the settlement date, subject to paragraph 9.4, and other provisions of this article. The Bangladesh Bank may refuse to permit the use of credit given for a debit item if it judges that there may not be sufficient funds in the sending bank’s settlement account to cover chargeback or return of the item.
9.10.2 Credit given by the Bangladesh Bank for a credit item is final and available for use and
may qualify as reserve.
SECTION 9.11 Receiving Bank’s Agreements
9.11.1 A receiving bank, by maintaining or using an account with the Bangladesh Bank for
settlement of items or by accepting an item from the Bangladesh Bank:
(a) agrees to comply with the applicable BEFTN rules and agrees that those rules govern the relationships among the sending bank, the receiving bank and other parties interested in the item and covered by those rules; (b) agrees to process the item in accordance with this Article; (c) agrees that the Bangladesh Bank processes the item as the BEFTN operator and does not collect, present, or return the items as “collecting” or “returning” bank; (d) authorizes the Bangladesh Bank to credit the amount of a credit item, or debit the amount of a debit item to the receiving bank’s settlement account on the settlement date; and (e) agrees to indemnify the Bangladesh Bank for any loss or expense (including attorneys’ fees and expenses of litigation) incurred as a result of a breach of the foregoing agreements or of any action taken by the Bangladesh Bank in accordance with its Rules.
9.11.2 The agreements, authorization and indemnity in paragraph 9.11.1 do not limit any
other agreement, authorization or indemnity not inconsistent with paragraph 9.11.1 made by a receiving bank to a sending bank, the Bangladesh Bank or another person.
SECTION 9.12 Revocation of Items
9.12 1 A sending bank may not amend or revoke an item after it has been sent to the
Bangladesh Bank, except as provided in applicable BEFTN rules.

9.12.2 The Bangladesh Bank may cancel items by initiating a reversing batch of items in
accordance with applicable BEFTN rules if it discovers that the Bangladesh Bank sent a duplicate or erroneous batch of items. The Bangladesh Bank will notify the sending bank accordingly. Nothing in these Rules constitutes a waiver by any Bangladesh Bank of a right of recovery under the applicable law of mistake and restitution.
SECTION 9.13 Return of Items and Funds
9.13.1 A receiving bank may return a debit or credit item to the Bangladesh Bank in
accordance with the applicable BEFTN rules and by the deadline set forth in the BEFTN time
schedule. The receiving bank is accountable for the amount of a debit item if the returned
item is not received by that deadline.
9.13.2 The Bangladesh Bank processes a returned item it receives from a receiving bank and
sends it or makes it available to the sending bank in accordance with the provisions of these Rules governing the processing of items. On the settlement date, the Bangladesh Bank debits or credits the settlement account of the receiving bank in the amount of a returned debit or credit item, and credits or debits the settlement account of the sending bank in the amount of the returned debit or credit item
SECTION 9.14 Disputed Returns
If a sending bank disputes the propriety of a returned item one time in accordance with applicable BEFTN rules, the Bangladesh Bank will provisionally settle for the disputed return, subject to receipt of funds from the receiving bank. If the receiving bank disputes the sending bank’s claim in accordance with applicable BEFTN rules, the Bangladesh Bank will reverse the provisional settlement for the disputed return, subject to receipt of funds from the sending bank.
SECTION 9.15 Advices of Credit and Debit; Reporting of Errors
The Bangladesh Bank provides advices of credit and debit to an account holder for items for which the account holder has agreed to settle. An advice of credit indicates that credit has been given, subject to the provisions of these Rules The Bangladesh Bank also, on request, provides advices to a person other than the bank or its correspondent, as the bank’s agent.
SECTION 9.16 Records
Each sending and receiving bank must keep records for six years that permit it to resolve questions that arise concerning the handling of items, and to resend items if the Bangladesh Bank notifies it that the items have been lost because of a computer outage or other reason. The Bangladesh Bank keeps records of items processed for twelve years after the settlement date.
SECTION 9.17 Fees
Bangladesh Bank shall charge fees for processing all BEFTN items and will provide notification to Participating Banks of such fees from time to time. In addition Bangladesh Bank may impose a penalty to a Participating Bank for violating the Rules and other instructions to this regard.
SECTION 9.18 NonValue Messages
The Bangladesh Bank handles a message that does not result in an accounting entry, such as a notification of change, in the same manner as an item except that no funds are transferred. The Bangladesh Bank’s liability for damage caused by its failure to exercise ordinary care or by its own or its employees’ wilful misconduct, in processing a non‐value message may not exceed the amount of any fee paid to the Bangladesh Bank for the message.

SECTION 9.19 Bangladesh Bank Liability
9.19.1 Limitation of Liability
(a) the Bangladesh Bank is responsible or liable only to a sending bank, and a receiving bank only for its own failure to exercise ordinary care, or for its own or its employees’ wilful misconduct; (b) the Bangladesh Bank does not act as the agent or subagent of another bank or person and is not liable for the insolvency, neglect, misconduct, mistake or default of another bank or person; (c) the Bangladesh Bank does not make any warranty with respect to an item it processes or settles for under these Rules and (d) no banking company may make a claim against the Bangladesh Bank for loss resulting from the Bangladesh Bank’s processing of or settling for an item after one year from the settlement date of the item. If a bank (or correspondent bank, if any) does not send written objection to an advice of debit to the Bangladesh Bank within thirty calendar days after receipt of the advice, it is deemed to approve the debit on its own behalf (and on behalf of a sending or receiving bank using the account for settlement, if any).
9.19.2 The measure of damages for the Bangladesh Bank’s failure to exercise ordinary care,
or for its own or its employees’ wilful misconduct is as follows:
(a) For a credit item (including a returned credit item), its liability is limited to damages that are attributable directly and immediately to the failure to exercise ordinary care or to the wilful misconduct, and does not include damages that are attributable to the consequences of such conduct, even if such consequences were foreseeable at the time of such conduct. (b) For a debit item (including a returned debit item), its liability for its failure to exercise ordinary care is limited to the amount of the item reduced by an amount that could not have been realized by the use of ordinary care. Where there is wilful misconduct with respect to a debit item, the measure of damages includes other damages that are attributable directly and immediately to the wilful misconduct, but does not include damages that are attributable to the consequences of such misconduct, even if such consequences were foreseeable at the time of such misconduct.
SECTION 9.20 As of Adjustments
The Bangladesh Bank, in its discretion, may satisfy its obligation to pay compensation in the form of interest by:
(a) providing an as of adjustment to a sending or receiving bank in an amount equal to the amount on which interest is to be calculated multiplied by the number of days for which interest is to be calculated; or (b) paying compensation in the form of interest to a sending bank, receiving bank or another party to the item that is entitled to such payment
SECTION 9.21 Right to Amend
The Bangladesh Bank reserves the right to amend this Article at any time without prior notice with the consent of the Bangladesh Bank Board.

ARTICLE TEN
DEFINITION OF TERMS
SECTION 10.1 Definitions As Used In These Rules
(1) “Alphanumeric” means any character 0 ‐ 9, A ‐ Z, a‐z, blank, and printable special characters which have an ASCII value greater than hexadecimal 1F. Fields defined in these Rules as “alphanumeric” may contain any of these allowable characters. (2) “ANSI ASC X12.5” (Interchange Control Structure) means the standard to define the control structures for the electronic interchange of business transactions encoded in ASC X12‐based syntax. This standard provides the interchange envelope of a header and trailer for the electronic interchange through a data transmission, a structure to acknowledge the receipt and processing of this envelope, and optional, interchange‐level service request structures. (3) “ANSI ASC X12.6” (Application Control Structure) means the standard used to define the structure of business transactions for computer‐to‐computer interchange. This structure is expressed using a symbolic representation of X12 data in terms of both the design and use of X12 structures, independent of the physical representation (e.g., character set encoding). (4) “BEFTN” means a funds transfer system operator governed by the Rules of the BEFTN Membership which provides for the inter bank clearing of electronic entries for participating Banks. (5) “BPR or BPS Data Segment” or “Beginning Segment for Payment Order/Remittance Advice” means the beginning segment for the payment order/remittance advice used in ASC X12‐ based syntax to indicate the beginning of a payment‐related transaction set which contains the necessary Banking information to process the transaction. (6) “Banking Day” means, with reference to a Participating Bank, any day on which such Bank is open to the public during any part of such day for carrying on substantially all of its Banking functions, and, with reference to the BEFTN, and any day on which the appropriate facility of such EFT Operator is being operated. (7) “Business Day” means a calendar day other than Friday, Saturday or National holiday. (8) “Corporate Debit or Credit” means a credit or debit entry initiated by an organization to consolidate funds of that organization from its branches, franchises or agents, or from other organizations, or to fund the accounts of its branches, franchises or agents, or of another organization. (9) “Consumer Debit or Credit” means a credit entry initiated by or on behalf of the holder of a Consumer Account to affect a transfer of funds to the account of the Receiver. (10) “Consumer Account” means an account held by a Participating Bank and established by a natural person primarily for personal, family or household and not for commercial purposes. (11) “Consumer Entry” means a credit or debit entry initiated by an organization pursuant to a standing or a single entry authorization from a Receiver to affect a transfer of funds to or from a Consumer Account of the Receiver. (12) “Electronic” means relating to technology having electrical, digital, magnetic, wireless, optical, electromagnetic,
or similar capabilities.

(13) “Electronic Record” means an agreement, authorization, written statement, or other record created, generated, sent, communicated, received, or stored by electronic means. (14) “Electronic Signature” means an electronic sound, symbol, or process attached to or logically associated with an agreement, authorization, written statement, or other record and executed or adopted by a person with the intent to sign the record. (15) “Entry” means an order or request complying with the requirements of Appendix Two (BEFTN Record Format Specifications) (1) for the transfer of money to the account of a Receiver (a “credit entry”), (2) for the withdrawal of money from the transaction account or general ledger account of a Receiver (a “debit entry”), (3) a zero Taka entry. For all entries except re‐presented cheque entries, each debit entry shall be deemed an “item”. (16) “Entry data” means, as applicable, returned entries, adjustment entries, notifications of change and/or other notices or data transmitted through the BEFTN pursuant to these Rules. (17) “File” means a group of entries complying with the requirements of Appendix Two (BEFTN Record Format Specifications), associated with a given transmittal register and the control totals set forth therein. (18) “Inbound entry” means an entry that originates in another country and is transmitted to The People's Republic of Bangladesh. (19) “Non‐Settled entry” means an entry for which settlement cannot be completed under the rules governing the settlement of that entry. (20) “Organization” means a corporation, partnership, association or other entity, governmental or private, or a natural person, provided that, in the case of a natural person, any account of such person to be debited or credited with the amount of any entry is maintained primarily for commercial and not for personal, family or household purposes. (21) “Originating Banking Company” or “OB” means a originating banking company with respect to entries (1) it transmits directly or indirectly to the BEFTN Operator for transmittal to an RB, and (2) on which it is designated as the OB in accordance with Appendix Two (BEFTN Record Format Specifications). (22) “Originator” means a person that has authorized an OB to transmit (1) a credit entry to the account of a Receiver with a RB, or, if the Receiver is also the RB, to such Receiver, or (2) a debit entry to the Receiver’s transaction account or general ledger account with a RB, or, if the Receiver is also the RB, to such Receiver. (23) “Participating Bank” means a Bank that (1) is authorized by law to accept deposits, (2) has been assigned a routing number by BEFTN authority (Bangladesh Bank), and (3) has agreed to be bound by these Rules as in effect from time to time. Only Participating Banks may act as OBs or RBs. (24) “Person” means a natural person or an organization. (25) “Private Sector Operator”: means an entity that executes an annual agreement with BEFTN in which the entity agrees to comply
with or perform all of the following:

adhere to these Rules (except to the extent inconsistent with the policies or
practices of the Bangladesh Bank) and other applicable laws, regulations, and policies;
execute agreements with Participating Banks that bind such entities to the Private
Sector Operator’s rules and to these Rules (except that the Bangladesh Bank shall not be required to bind a Participating Bank to any provision of such rules of Private Sector Operator that is not incorporated by these rues;
provide clearing, delivery, and settlement services for Private Sector Operator’s
entries, as defined by these Rules, between Participating Banks that have selected the Private Sector Operator to perform EFT services;
process and edit files based on the requirements of these Rules;
evaluate the credit worthiness of and apply risk control measures to their
Participating Banks;
adhere to the Bangladesh Bank’s Policy Statement on Multilateral Settlement
Systems (as applicable); and
adhere to any BEFTN Performance Standards as they are developed.
(26) “Record” means information that is inscribed on a tangible medium or that is stored in an electronic or other medium and is retrievable in perceivable form. (27) “Receiver” means a person that has authorized an Originator to initiate (1) a credit entry to the Receiver’s account with a RB, or, if the Receiver is also the RB, to such Receiver, or (2) a debit entry to the Receiver’s transaction account or general ledger account with a RB, or, if the Receiver is also the RB, to such Receiver. With respect to debit entries, the term “Receiver” shall be deemed to mean all persons whose signatures are required to withdraw funds from an account for purposes of the warranty provisions of subsection 2.2.1 (Warranties). (28) “Receiving Banking Company” or “RB” means a Participating Bank that is an RB with respect to entries (1) it receives from its BEFTN Operator for debit or credit to the accounts of Receivers, and (2) on which it is designated as the RB in accordance with Appendix Two (BEFTN Record Format Specifications). (29) “Send” means to deposit in the mail or to communicate by any other usual means with postage or cost of transportation provided for and properly addressed, or by facsimile. (30) “Settlement Date” means the date an exchange of funds with respect to an entry is reflected on the books of the Bangladesh Bank. (31) “Single Entry” means a one‐time transfer of funds initiated by an Originator in accordance with the Receiver’s authorization for a single BEFTN credit or debit to the Receiver’s Consumer Account. (32) “Transmit” means to deliver by electronic means of communication. (33) “Zero Entry” means an entry which carries a zero amount but does include payment related remittance data. Zero entries are limited to corporate entries that carry remittance data related to the payment. For example, pre‐advice entries that carry remittance data that indicates a credit position of the Originator to the Receiver, or entries relating to a period of time during which no funds are owed by the Originator to the Receiver.
SECTION 10.2 Construction Rules
Unless the context otherwise requires, words in a singular number include the plural, and in the plural include the singular. The term “section” refers to a subdivision of an Article containing a two‐ digit number (e.g., “2.1”); the term “subsection” refers to a subdivision of a section containing a three or four‐digit number (e.g., “2.1.1”).

SECTION 10.3 Other definitions
(1) Access: the right of or opportunity for an institution to use the EFT services of BEFTN system to settle payments on its own account or for customers. (2) Addenda record: an EFT record type that carries the supplemental data needed to completely identify an account holder or provide information concerning a payment to the RB and the receiver. (3) Automated Clearing House: the EFT Network is a multilateral electronic clearing system in which cheques and other payment instructions are being exchanged among Schedule Banks. The system involves transmitting, reconciling and calculating the net position of each individual participant at the end of a transaction period. (4) Automated teller machine: an electromechanical device that permits authorized users, typically using machine‐readable plastic cards, to withdraw cash from their account and/or access other services, such as balance enquiries, transfer of funds or acceptance of deposits. ATMs may be operated either online with real‐time access to an authorization database or offline. (5) Banking day: any day on which a participating bank is open to the public during any part of the day for carrying on substantially all its banking function. (6) Banking System: all Banks that in particular accept deposits, provide and/or offer payment services directly to users as one of their core business functions. This includes the central bank as well. (7) Batch: the transmission of processing of a group of payment instructions and/or security transfer instructions as a set at discrete time interval. (8) Business continuity: a payment system’s arrangements which aim to ensure that it meet agreed service levels even if one or components of the system fails or if it is affected by an abnormal external event. Include both preventive measures and arrangements to deal with contingencies. (9) Central Depository Bangladesh Ltd. (CDBL) a facility for holding the securities which enables securities transactions to be processed by book entry. Physical securities may be immobilized by the depository or securities are dematerialized (i.e. so that they exist only as electronic records). In addition to safekeeping, CDBL or some other organization like it may incorporate comparison and clearing function as well. (10) Clearing: the process of transmitting, reconciling and in some cases, confirming payment instructions or security transfer instructions prior to settlement, possibly including the netting of instructions and the establishment of final positions for settlement. Sometimes the term is used (imprecisely) to include settlement. (11) Collateral: an asset pledged by a borrower to secure a loan or other credit, and subject to seizure in the event of a default, also called security. (12) Confirmation: a process whereby a market participant notifies its counterparties or customers of the details of a trade and typically allows them time to affirm or to question the trade. (13) Consumer account: a deposit account held by a
bank and established by a natural person primarily for personal, family or household use and not for commercial purpose. (14) Correspondent banking: an arrangement under which one bank (correspondent) holds deposits owned by other banks (respondents) and provides payment and other services to

those respondent banks. Such arrangements may also be known as agency relationships in some domestic context. (15) Counter party: the opposite party to a financial transaction such as a securities trade or swap agreement. (16) Credit risk: the risk that a counterparty will not settle an obligation for full value, either when due or any time thereafter. In exchange‐for‐value systems, the risk is generally defined to include replacement cost risk and principle risk. (17) CSE: Chittagong Stock Exchange. (18) Custody: the safekeeping of financial documents and instruments (19) Data Transmission: the electronic exchange of information between two data processing points. (20) Delivery versus Payment: a link between a security transfer system and a fund transfer system that works simultaneously to ensure that delivery occurs if, and only if, payment occurs. (21) Dematerialization: the elimination of physical certificates or documents of title which represent ownership of securities so that securities exist only as accounting records. (22) Depository: an agent with the primary role of recording securities either physically or electronically and keeping records of the ownership of these securities (23) Direct debit: a method of collection used in EFT for certain claims, generally those that are repeated over a period of time, under which the debtor gives his or her bank authorization to debit his or her account upon the receipt of an entry issued by a creditor. (24) Direct Deposit: an EFT service that provides for the electronic transfer of funds directly into the account of a payee, usually an employee receiving salary or social security benefits. (25) DSE: Dhaka Stock Exchange. (26) Effective Entry Date: the date the originator expects payment to take place. The BEFTN reads the effective entry date to determine the settlement date. (27) Electronic Funds Transfer (EFT): a generic term used to describe any Electronic Funds Transfer. (28) Entry: an electronic item representing the transfer of funds in the EFT. (29) Field: one or more consecutive character positions within an EFT entry mapped to contain specific information. For credit, debit or ATM cards, a defined area within an information track of the magnetic stripe of fixed or variable length. (30) File: a group of EFT batches initiated into the EFT Network or sorted for delivery to EFT by an OB on behalf of a respondent bank. A file must be transmitted electronically via data transmission in between the OB and the BEFTN. A file may be delivered to an end‐point via direct data transmission, CD, or other magnetic media. A file may contain one or more batches of entries. (31) Funds Availability: the time at which the funds resulting from a funds transfer are made available to the customer. (32) End user: a customer of a bank to which the bank provides payment instruments and services to facilitate the completion of their financial transactions (33) Finality: irrevocable and unconditional

(34) Gross settlement system: a transfer system in which the settlement of funds or securities transfer instruction occurs individually (on a transaction by transaction basis) (35) Immobilization: placement of physical certificates of securities and financial instruments in a central depository so that subsequent transfer can be made by book entry (36) Institutional arrangements: a transfer and organizational arrangement to provide various types of payment services from bank and other organization to users. They include market arrangements, the legal and regulatory framework, and mechanisms for consultation and coordination among stakeholders in the national payment system. (37) Interoperability: a situation in which payment instruments belonging to a given scheme may be used in systems installed by other schemes. Interoperability requires technical compatibility between systems, but can only take effect where commercial agreements have been concluded between the schemes concerned. (38) Intraday credit: credit extended for a period of less than one business day; in a credit transfer system with end‐of‐day final settlement, intraday credit is obviously extended to the receiving bank if it accepts and acts on a payment order even though it will not receive final funds until the end of the business day. Also called daylight overdraft, daylight exposure and daylight credit. (39) Intraday liquidity: funds which can be accessed during the business day, usually to enable Banks to make payments in real time. (40) Large‐value‐payments: a payment generally involving a very large amount, which is mainly exchanged between banks or between participants in the financial markets and usually requires urgent and timely settlement. They are often related to important financial market transactions such as money market of foreign exchange transactions as well as many commercial transactions. (41) Legal risk: the risk of loss because of the unexpected application of a law or regulation or because a contract cannot be enforced. (42) Liquidity risk: the risk that a counterparty (or participant in a settlement system) will not settle an obligation for full value when due. Liquidity risk does not imply that a counterparty or participant is insolvent since it may be able to settle the required debt obligation at some unspecified time thereafter. (43) Loss sharing agreement: an agreement among participants in a clearing or settlement system regarding the allocation of any losses arising from the default of a participant in the system or of the system itself. (44) Magnetic Ink Character Recognition (MICR): a special type of ink which creates a machine‐ readable image. This MICR code line is inputted at the bottom of every cheque that comes to a Bangladesh Electronic Cheque Processing system. (45) NACHA: National Automated Clearing House Association is the association that establishes the standard, rules and procedures that enable banks to exchange EFT payments on a
national basis in the USA. (46) National payment system: the institutional and infrastructure arrangements in a financial system for initiating and transferring monetary claims in the form of commercial bank and central bank liability. (47) Net settlement system: a settlement system in which final interbank settlement of individual transfer instructions occurs on a net basis at one or more discrete, specified times during a processing day.

(48) Netting: an agreed offsetting of positions or obligations by trading partners or participants. The netting reduces a large number of individual positions or obligations with similar counter party obligations and ends up with one figure. Netting may take several forms, which have varying degrees of legal enforceability in the event of default of one of the participants. (49) Network operations: all the processes and arrangements related to the functioning of a network (such as those related to operating hours, fees, sanctions, delivery of items, formats etc.) (50) Novation: the replacement of existing obligations by new obligations between the existing or substitute parties that satisfactory and legally discharge the original obligation. (51) On‐us Entry: entry within an EFT file destined for an account holder at the Originating Bank. (52) Operational risk: the risk that deficiencies in information systems or internal controls could result in unexpected losses. (53) Oversight: a central bank function whereby the objectives of safety and efficiency in payment and settlement systems are promoted by monitoring existing and planned systems, accessing them against these objectives and where necessary, including change. (54) Payment: the payer’s transfer of a monetary claim on a party acceptable to the payee. Typically, monetary claims take the form of banknotes or deposit balances held at a Banks or at a central bank. (55) Payment infrastructure: the entirety of network facilities, technologies and procedures for accessing and transacting payment instruments and for processing, clearing and settling related payments. (56) Payment infrastructure services: services provided through the payment infrastructure for accessing and transacting payment instruments and for processing, clearing and settling related payments. (57) Payment order (instruction): an order or message requesting the transfer of funds to the order of the payee. The order may relate either to a credit transfer or to a debit transfer. Also called payment instructions. (58) Payment service markets: arrangements that coordinate the production and pricing of payment instruments and services and their delivery from payment service providers to users. Particular markets are characterized by their specific market practices, service providers and users, and factors influencing the demand for and supply of that specific service. (59) Payment system: a specific set of instruments, banking procedures and interbank fund transfer system that ensures the circulation of money. (60) Posting: the process of recording debits and credits to individual account balances. (61) Principal risk: the risk that the seller of a security delivers a security but does not receive payment or that the buyer of a security makes payment but does not receive delivery. In this event, the full principal value of the security of funds transferred is at risk. (62) Real‐time transfer: the transmission, processing and
settlement of a funds or securities transfer instructions at the time that it is initiated. (63) Retail payment: a payment between various consumers, businesses and governments of relatively low value and urgency. It is a payment which is not captured in the definition of a large‐value payment.

(64) Retail payment infrastructure: mechanisms used for transaction, clearing and settlement of relatively low‐value non‐urgent payments initiated through payment instruments such as cheques, drafts, payment orders, EFT credit transfers, EFT direct debits, card payments etc. (65) Return: any EFT entry that has been returned to the originating bank by the receiving bank or by the BEFTN because it cannot be processed. The reasons for each return are included with the return in the form of a “return reason code”. (66) Reversal: any EFT entries or files sent within required deadlines to “correct” or reverse previously originated erroneous entries or files. (67) Routing Number: a nine digit number that identifies a specific bank branch. These numbers are assigned by Bangladesh Bank. (68) SEC Codes: each EFT transaction is identified and recognized by a three‐digit code known as the Standard Entry Class (SEC) Code, from which the type of payment and as well as the consumer/corporate application might be understood. (69) Securities infrastructure: full set of arrangements for the trading, registration and custody of securities and for the confirmation, clearance and settlement of security transactions. (70) Security system: the institutional arrangements and infrastructure for issuing and administering securities liabilities, administering and safekeeping holdings of securities issues, and initiating, confirming, matching, transferring and settling securities transactions. (71) Settlement: a transfer of funds between two (or more) parties in cash, or on the books of a scheduled bank, to complete one or more prior transactions, made subject to final accounting. Settlement for the EFT Network usually occurs through the Bangladesh Bank. (72) Settlement Date: the date on which an exchange of funds with respect to an entry is reflected on the books of the BB’s account. (73) Settlement risk: general terms used to designate the risk that settlement in a transfer system will not take place as expected. This risk may comprise both credit risk and liquidity risk. (74) Stakeholder: in a payment system stakeholders are those parties whose interests are affected by the operation of the system. (75) Straight through processing: the automated end‐to‐end processing of trades/payment transfers including the automated completion of confirmation, matching, generation, clearing and settlement orders. (76) Systemic risk: the risk that the failure of one participant in a transfer system, or in financial market generally, to meet its required obligations will cause other participants or Banks to be unable to meet their obligations (including settlement obligations in a transfer system) when due. Such a failure may cause significant liquidity or credit problems and as a result, might threaten the stability of financial markets. (77) Systemically Important Payment System (SIPS): a payment system is systemically important where, if the system were insufficiently protected
against risk, disruption within it could trigger or transmit further disruptions amongst participants or systemic disruption in the financial area more widely. (78) Transaction Code: the two digit code in the EFT record that determines whether an entry is a debit or a credit to a savings account, general ledger account or whether an entry is a credit to a loan account.

THE APPENDICES
TECHNICAL SPECIFICATIONS
BEFTN PARTICIPATION AGREEMENT

APPENDIX ONE
BEFTN FILE EXCHANGE SPECIFICATIONS
The following information outlines the requirements for processing electronic transmissions, addresses the sequence of records in a BEFTN file, and gives a descriptive overview of the various logical records contained in a file.
SECTION 1.1 Electronic Transmission Requirements
To ensure compatibility in electronic file transmission, necessary operating details (testing and implementation plans) need to be addressed between a Participating Bank and BEFTN.
SECTION 1.2 BEFTN CD/DVD Specifications
(Contingency use only, subject to approval by the BEFTN) In contingency situations, data may be submitted on CD/DVD media, each record must be terminated by CRLF character sequence.
SECTION 1.3 Data Specifications
All alphanumeric and alphabetic fields must be left justified and space filled. All numeric fields must be right justified, unsigned, and zero filled. Characters used in BEFTN records are restricted to 0‐9, A‐ Z,a‐z, space, and those special characters an ASCII value greater than hexadecimal “1F”. Occurrences of values ASCII “00” ‐ “1F” are not valid.
SECTION 1.4 Sequence of Records in BEFTN Files
Each file begins with a File Header Record. After the File Header may be any number of batches. Each batch is identified by a Batch Header Record and contains one or more Entry Detail Records. The number of addenda records that accompany each entry is dependent upon the Standard Entry Class Code. At the end of each batch is a Batch Control Record. Each file is ended with a File Control Record. The records in BEFTN files must be in the following sequence:

File Header Record
Batch #1
Company/Batch Header Record
Entry Detail Records or Corporate Entry Detail Records (with/without optional Addenda Records) Company/Batch Control Record Batch #2 Company/Batch Header Record Entry Detail Records or Corporate Entry Detail Records (with/without optional Addenda Records) Company/Batch Control Record Batch #n Company/Batch Header Record Entry Detail Records or Corporate Entry Detail Records (with/without optional Addenda Records) Company/Batch Control Record File Control Record

Any other sequence will cause the file to be rejected (see diagrams on the following pages).
SECTION 1.5 File Structure
File Header Record
The File Header Record designates physical file characteristics and identifies the immediate origin ( or BEFTN) and destination ( or BEFTN) of the entries contained within the file or within the transmitted batched data. In addition, this record includes date, time, and file identification fields which can be used to identify the file uniquely. Company/Batch Header Record The Company/Batch Header Record identifies the Originator and briefly describes the purpose of the entry. For example, “GAS BILL” or “SALARY” indicates the reason for the transaction originated by the Originator. The Company/Batch Header Record contains the Routing Number of the OB for settlement, routing of returns, and other control purposes. In addition, the Company/Batch Header Record can indicate the intended effective entry date of all transactions within the batch. The information contained in the Company/Batch Header Record applies uniformly to all subsequent Entry Detail Records in the batch. Entry Detail Record, Corporate Entry Detail Record Entry Detail Records contain that information sufficient to relate the entry to the Receiver, i.e., individual BANK account number, identification number, name, and the debit or credit amount as indicated by the Transaction Code. The information in the Company/Batch Header Record must be incorporated with the Entry Detail Records to describe fully that entry and all participants in the transaction. The information in the Company/Batch Header Record identifies the Originator; the Trace Number identifies the OB; BANK account information identifies both the RB and the specific account. In addition to the basic entry format, Transaction Codes for Entry Detail Records have been defined to accommodate zero Taka entries, and return entries. Zero entries are identical to the basic entry format but contain appropriate Transaction Codes and zeros in the Amount field. Zero entries can be batched with other entries or batched separately. A zero entry must be accompanied by at least one Addenda Record. Return entries are distinguished by special Transaction Codes and must be batched separately from other Taka entries. Addenda Record Addenda records will be used by the Originator to supply additional information about Entry Detail Records that will be passed from the OB through the BEFTN to the RB. Addenda records associated with the original Entry Detail Record or Corporate Entry Detail Record will not be included with any Entry Detail Record being returned. Only BEFTN sanctioned formats will be permitted, as specified by the Addenda Type Code. Addenda record information may only be used for the purpose of transmitting payment related information. Any other use is prohibited. Each application and its corresponding number of addenda records are listed below:
APPLICATION CONTENTS MAX ‐ ADDENDA Mandatory/Optional CCD See Appendix 2 1 Optional CIE See Appendix 2 1 Optional NOC See Appendix 2 1 Mandatory CTX See Appendix 2 9,999 Optional PPD See Appendix 2 1 Optional

APPLICATION CONTENTS MAX ‐ ADDENDA Mandatory/Optional RETURNS See Appendix 5 1 Mandatory TRX See Appendix 2 9,999 Mandatory Company/Batch Company/Batch Control Record The Company/Batch Control Record contains the counts, hash totals, and total Taka controls for the preceding detail entries within the indicated batch. All Entry Detail Records are hashed. Both Entry Detail Records and Addenda Records are included in the entry/addenda counts; Batch Header and Batch Control Records are not included. File Control Record The File Control Record contains Taka, entry, and hash total accumulations from the Company/Batch Control Records in the file. This record also contains counts of the number of blocks and the number of batches within the file (or batched data transmitted to a single destination). Sequence of Records:
SECTION 1.6 Trace Number Sequence in BEFTN Files
Banks must always prepare files so that individual Entry Detail Records within individual batches are in ascending Trace Number order (although Trace Numbers need not necessarily be consecutive). The Trace Number in an Addenda Record is the same as that of the Entry Detail Record with which the Addenda Record is associated. Addenda Records must be in consecutive ascending order by the Addenda Sequence Number. File Header Record File Control Record Batch Header Record Batch Control Record Batch Header Record Batch Control Record Entry Detail Record Entry Detail Record Entry Detail Record Entry Detail Record One per file - First logical record One per batch One per batch Batch 1 Batch N Batches 2-N One per file, last logical record

APPENDIX TWO
BEFTN RECORD FORMAT SPECIFICATIONS
The BEFTN record format specifications are designed to assist BEFTN participants in properly formatting and retrieving transaction information. This section details the contents of the various record formats and defines the code values and data elements. The inclusion requirements, contents, and lengths of data elements are illustrated in the record formats, which are arranged according to their sequence in the file. The glossary defines and explains the application of each field.
SECTION 2.1 BEFTN Record Formats
On the following pages are the BEFTN record formats. The first record formats (2.1.1) are the File Header and File Control Records. These two records act as the outermost envelope of a BEFTN transaction and convey information related to the destination and origin of the transaction as well as the total amount of debits and credits within the file. The format of these records is consistent for all entries, regardless of the Standard Entry Class Code. The second set of record formats (2.1.2) contains the Company/Batch Header and Company/Batch Control Records. The Batch Records act as an inner envelope combining similar entries and providing information about the Originator. Like the File Records, the format of these records is consistent for all entries, regardless of the Standard Entry Class Code. The remaining Sequence of Records (2.1.3 ‐ 2.1.23) contains the Entry Detail Records and Addenda Records according to Standard Entry Class Code.
2.1.1 BEFTN File Record Format for All Entries
All Entries File Header Record
FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13
E RECORD
TYPE
CODE
PRIORITY
CODE
IMMEDIATE
DESTINATION
IMMEDIATE
ORIGIN
FILE
CREATION
DATE
FILE
CREATION
TIME
FILE ID
MODIFIER
RECORD
SIZE
BLOCKING
FACTOR
FORMAT
CODE
IMMEDIATE
DESTINATION
NAME
IMMEDIATE
ORIGIN
NAME
REFERENCE
CODE
Field
Inclusion
Requirement
M R M O M O
Contents ‘1' Numeric bTTTTAAAAC bTTTTAAAAC YYMMDD HHMM UPPER CASE A‐Z NUMERIC 0‐9 ‘094' ‘10' ‘1' Alphanumeric Length 1 2 10 10 6 4 1 3 2 1 23 23 8 All Entries File Control Record FIELD 1 2 3 4 5 6 7 8 DATA ELEMENT NAME RECORD TYPE CODE BATCH COUNT BLOCK COUNT ENTRY/ ADDENDA COUNT ENTRY HASH TOTAL DEBIT ENTRY TAKA AMOUNT IN FILE TOTAL CREDIT ENTRY TAKA AMOUNT IN FILE RESERVED Field Inclusion Requirement M N/A Contents ‘9' Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Blank Length 1 6 6 8 10 12 12 39

2.1.2 BEFTN Batch Record Format for All Entries
Company Batch Header/Trailer (Control) Records All Entries Company/Batch Header Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE COMPANY NAME COMPANY DISCRETIONARY DATA COMPANY IDENTIFICATIO N STANDARD ENTRY CLASS CODE COMPANY ENTRY DESCRIPTION COMPANY DESCRIPTIV E DATE EFFECTIVE ENTRY DATE SETTLEMENT DATE (JULIAN) ORIGINATO R STATUS CODE ORIGINA TING BANK IDENTIFI CATION BATCH NUMBER Field Inclusion Requirement M O M O R Inserted by EFT Operator M Contents ‘5' Numeric Alphanumeric Alphanume ric Alphanumeric Alphanume ric YYMMDD Numeric Alphanume ric TTTTAAA A Numeric Length 1 3 16 20 10 3 10 6 6 3 1 8 7 All Entries Company/Batch Control Record
2.1.3 Sequence of Records for ADV Entries
Adv File Header Record
FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
PRIORITY
CODE
IMMEDIATE
DESTINATION
IMMEDIATE
ORIGIN
FILE
CREATION
DATE
FILE
CREATION
TIME
FILE ID
MODIFIER
RECORD
SIZE
BLOCKING
FACTOR
FORMAT
CODE
IMMEDIATE
DESTINATION
NAME
IMMEDIATE
ORIGIN
NAME
REFERENCE
CODE
Field
Inclusion
Requirement
M R M O M O
Contents ‘1' Numeric bTTTTAAAAC bTTTTAAAAC YYMMDD HHMM UPPER CASE A‐Z NUMERIC 0‐9 ‘094' ‘10' ‘1' Alphanumeric Length 1 2 10 10 6 4 1 3 2 1 23 23 8 Adv File Control Record FIELD 1 2 3 4 5 6 7 8 DATA ELEMENT NAME RECORD TYPE CODE BATCH COUNT BLOCK COUNT ENTRY/ ADDENDA COUNT ENTRY HASH TOTAL DEBIT ENTRY TAKA AMOUNT IN FILE TOTAL CREDIT ENTRY TAKA AMOUNT IN FILE RESERVED Field Inclusion Requirement M N/A Contents ‘9' Numeric $$$$$$$$$$$$$$$$$$¢¢ $$$$$$$$$$$$$$$$$$¢¢ Blank Length 1 6 6 8 10 20 20 23 FIELD 1 2 3 4 5 6 7 8 9 10 11 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE ENTRY/ ADDENDA COUNT ENTRY HASH TOTAL DEBIT ENTRY TAKA AMOUNT TOTAL CREDIT ENTRY TAKA AMOUNT COMPANY IDENTIFICATION MESSAGE AUTHENTICATION CODE RESERVED ORIGINATING BANK IDENTIFICATION BATCH NUMBER Field Inclusion Requirement M R O N/A M M Contents ‘8' Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Alphanumeric Alphanumeric Blank TTTTAAAA Numeric Length 1 3 6 10 15 15 10 19 6 8 7

2.1.3 Sequence of Records for ADV Entries (continued)
Adv Company/Batch Control Record
FIELD 1 2 3 4 5 6 7 8 9
DATA ELEMENT
NAME
RECORD
TYPE CODE
SERVICE
CLASS CODE
ENTRY/
ADDENDA
COUNT
ENTRY
HASH
TOTAL DEBIT ENTRY TAKA
AMOUNT
TOTAL CREDIT ENTRY
TAKA AMOUNT
ACH
OPERATOR
DATA
ORIGINATING BANK
IDENTIFICATION
BATCH
NUMBER
Field Inclusion
Requirement
M O M M
Contents ‘8' Numeric $$$$$$$$$$$$$$$$$$¢¢ $$$$$$$$$$$$$$$$$$¢¢ Alphanumeric TTTTAAAA Numeric Length 1 3 6 10 20 20 19 8 7 Adv Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA ELEMENT NAME RECORD TYPE CODE TRANS‐ ACTION CODE RECEIVING BANK IDENTIFI‐ CATION CHECK DIGIT BANK ACCOUNT NUMBER AMOUNT ADVICE ROUTING NUMBER FILE IDENTIFI‐ CATION ACH OPERATOR DATA INDIVIDUAL NAME DISCRE‐ TIONARY DATA ADDENDA RECORD INDICATOR ROUTING NUMBER OF EFT OPERATOR JULIAN DATE ON WHICH THIS ADVICE IS CREATED SEQUENCE NUMBER WITHIN BATCH Field Inclusion Requirement M R M M O O R O M Contents ‘6' Numeric TTTTAAAA Numeric Alphanumeri c $$$$$$$$$$¢¢ Numeric Alphanumeri c Alphanumeric Alphanumeric Alphanumeri c Numeric TTTTAAAA Numeric Numeric Length 1 2 8 1 15 12 9 5 1 22 2 1 8 3 4
2.1.4 Sequence of Records for CCD Entries
CCD Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
AMOUNT IDENTIFICATION
NUMBER
RECEIVING
COMPANY
NAME
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O R O M M
Contents ‘6' Numeric TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Numeric Length 1 2 8 1 17 12 15 22 2 1 15 CCD Addenda Record FIELD 1 2 3 4 5 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE PAYMENT RELATED INFORMATION ADDENDA SEQUENCE NUMBER ENTRY DETAIL SEQUENCE NUMBER Field Inclusion Requirement M M O M M Contents ‘7' ‘05' Alphanumeric Numeric Numeric Length 1 2 80 4 7 Position 01‐01 02‐03 04‐83 84‐87 88‐94

2.1.5 Sequence of Records for CIE Entries
CIE Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
AMOUNT INDIVIDUAL
NAME
INDIVIDUAL
IDENTIFICATION
NUMBER
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M R M O M M
Contents ‘6' Numeric TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Numeric Length 1 2 8 1 17 12 15 22 2 1 15 CIE Addenda Record FIELD 1 2 3 4 5 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE PAYMENT RELATED INFORMATION ADDENDA SEQUENCE NUMBER ENTRY DETAIL SEQUENCE NUMBER Field Inclusion Requirement M M O M M Contents ‘7' ‘05' Alphanumeric Numeric Numeric Length 1 2 80 4 7
2.1.6 Sequence of Records for CTX Entries
CTX CORPORATE ENTRY DETAIL RECORD
FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13
DATA
ELEMENT
NAME RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING
BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
TOTAL
AMOUNT
IDENTIFICATION
NUMBER
NUMBER
OF
ADDENDA
RECORDS
RECEIVING
COMPANY
NAME/ID
NUMBER
RESERVED
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O M R N/A O M M
Contents
‘6' Numeric TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric Numeric Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 CTX ADDENDA RECORD FIELD 1 2 3 4 5 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE PAYMENT RELATED INFORMATION ADDENDA SEQUENCE NUMBER ENTRY DETAIL SEQUENCE NUMBER Field Inclusion Requirement M M O M M Contents ‘7' ‘05' Alphanumeric Numeric Numeric Length 1 2 80 4 7

2.1.7 Sequence of Records for PPD Entries
PPD Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
AMOUNT INDIVIDUAL
IDENTIFICATION
NUMBER
INDIVIDUAL
NAME
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M R R O M M
Contents ‘6' Numeric TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Numeric Length 1 2 8 1 17 12 15 22 2 1 15 PPD Addenda Record FIELD 1 2 3 4 5 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE PAYMENT RELATED INFORMATION ADDENDA SEQUENCE NUMBER ENTRY DETAIL SEQUENCE NUMBER Field Inclusion Requirement M M O M M Contents ‘7' ‘05' Alphanumeric Numeric Numeric Length 1 2 80 4 7

2.1.8 Sequence of Records for TRX Entries
TRX Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING
BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
TOTAL
AMOUNT
IDENTIFICATION
NUMBER
NUMBER
OF
ADDENDA
RECORDS
RECEIVING
COMPANY
NAME/ID
NUMBER
RESERVED ITEM TYPE
INDICATOR
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O M R N/A O M M
Contents ‘6' Numeric TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric Numeric Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 TRX Addenda Record FIELD 1 2 3 4 5 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE PAYMENT RELATED INFORMATION ADDENDA SEQUENCE NUMBER ENTRY DETAIL SEQUENCE NUMBER Field Inclusion Requirement M M O M M Contents ‘7' ‘05' Alphanumeric Numeric Numeric Length 1 2 80 4 7
SECTION 2.2 Code Values
Addenda Record Indicator
Record Format Location: Entry Detail Record and Corporate Entry Detail Record 0 No addenda record follows the entry

1 One or more addenda records follow the entry Addenda Type Codes Record Format Location: Addenda Record 05 Addenda Record (Applies to CCD, CIE, CTX, PPD, and TRX Entries) 98 Automated Notification of Change (NOC) Addenda Record and Automated Refused Notification of Change (NOC) Addenda Record 99 Automated Return Entry Addenda Record, Automated Dishonoured Return Entry Addenda Record and Automated Contested Dishonoured Return Entry Addenda Record

Check Digit Routine Required for Bank Routing Number (ADV, CCD, CIE, CTX, PPD, TRX, dishonoured returns, contested dishonoured returns, NOC, refused NOC):
Subfield with Banking Company Identification – Mandatory.
The Check Digit is computed using Modulus 10 as follows:

Multiply each digit in the Routing Number by a weighting factor. The weighting factors for
each digit are:
Position: 1 2 3 4 5 6 7 8
Weights: 5 7 1 5 7 1 5 7
Add the results of the eight multiplications.
Subtract the sum from the next highest multiple of 10. The result is the Check Digit.
Example:
Routing No. : 0 7 6 4 0 1 2 5
Multiply by : 5 7 1 5 7 1 5 7
Sum : 0 49 6 20 0 1 10 35 = 121
Check Digit = 9 (130 minus 121)
Originator Status Codes
Record Format Location: Company/Batch Header Record 0 File prepared by BEFTN. 1 This code identifies the Originator as a Bank which has agreed to be bound by these Rules. 2 This code identifies the Originator as a government entity or agency not subject to these Rules.

Record Type Codes
Record Format Location: The first position of all record formats. These codes are uniquely assigned for each type of record as follows:
1 File Header Record Format
5 Company/Batch Header Record Format 6 Entry Detail Record Format (Consumer and Corporate) 7 Addenda Record Formats 8 Company/Batch Control Record Format 9 File Control Record Format Service Class Codes Record Format Location: Company/Batch Header Record and Company/Batch Control Record 200 BEFTN Entries Mixed Debits and Credits 220 BEFTN Credits Only 225 BEFTN Debits Only 280 BEFTN Automated Accounting Advices

Standard Entry Class Codes
Record Format Location: Company/Batch Header Record Transaction Codes Record Format Location: Entry Detail Record Current Credit Records (Current Deposit Accounts) 21 Automated Return or Notification of Change for original transaction code 22, 23, or 24 22 Automated Deposit 23 Prenotification of Demand Credit Authorization; 24 Zero Taka with remittance data (for CCD and CTX entries only); Current Debit Records (Current Deposit Accounts) 25 Reserved 26 Automated Return or Notification of Change for original transaction code 27, 28, or 29 27 Automated Payment 29 Zero Taka with remittance data (for CCD and CTX entries only)

Savings Account Credit Records
30 Reserved
31 Automated Return or Notification of Change for original transaction code 32, 33, or 34 32 Automated Deposit Savings Account Debit Records 35 Reserved 36 Automated Return or Notification of Change for original transaction code 37, 38, or 39 37 Automated Payment Bank General Ledger Credit Records 41 Automated Return or Notification of Change for original transaction code 42, 43, or 44 42 Automated General Ledger Deposit (Credit) Loan Account Credit Records 51 Automated Return or Notification of Change for original transaction code 52, 53, or 54 52 Automated Loan Account Deposit (Credit)

Loan Account Debit Records (for Reversals Only) 55 Automated Loan Account Debit (Reversals Only) 56 Automated Return or Notification of Change for original transaction code 55

Automated Accounting Records (for use in ADV files only) These transaction codes represent accounting entries and not actual BEFTN transactions. 81 Credit for BEFTN debits originated 82 Debit for BEFTN credits originated 83 Credit for BEFTN credits received 84 Debit for BEFTN debits received 85 Credit for BEFTN credits in rejected batches 86 Debit for BEFTN debits in rejected batches 87 Summary credit for respondent BEFTN activity 88 Summary debit for respondent BEFTN activity

SECTION 2.3 Glossary of File Format Data Elements
Field Inclusion Requirements
The following information defines the need for inclusion of certain data fields in BEFTN entries. This involves the standardization of three definitions: Mandatory, Required, and Optional. Mandatory for BEFTN Processing: A “Mandatory” field is necessary to ensure the proper routing and/or posting of a BEFTN entry. Any “Mandatory” field not included in a BEFTN record will cause that entry, batch, or file to be rejected by the BEFTN. A rejected entry will be returned to the OB by the BEFTN. A rejected batch or rejected file will be reported to the OB or by the BEFTN. Required: The omission of a “Required” field will not cause an entry reject at the BEFTN, but may cause a reject at the RB. An example is the BANK Account Number field in the Entry Detail Record. If this field is omitted by an OB, the RB may return the entry as unable to be posted. Data classified as “Required” should be included by the Originator and OB to avoid processing and control problems at the RB. Optional: The inclusion or omission of an “Optional” data field is at the discretion of the Originator and OB. However, if a BANK does originate files using optional data fields, these fields must be returned to the OB if the entry is returned.

Glossary of Data Elements
BEFTN Data (ADV): 35 Positions ‐ Company/ Batch Control Record ‐ Optional; 1 Position ‐ Entry Detail Record ‐ Optional This field is used as specified by the BEFTN.

APPENDIX THREE
SPECIFICATIONS FOR DATA ACCEPTANCE
The data acceptance criteria set forth below applies to entries submitted by s. Failure to meet such criteria will result in the rejection of an entire file, batch, or an individual entry by the BEFTN. A must select either the file level reject option or the batch level reject option and notify the BEFTN of its choice.
SECTION 3.1 File Acknowledgment
The BEFTN generates an acknowledgment for every file submitted for processing. The acknowledgment is in the form of a message or report transmitted or made available to the electronically. The BEFTN makes the acknowledgment available as soon as possible after the completion of the edits listed in sections 3.4 (Automatic File Rejection), 3.5 (Automatic Batch Rejection), and 3.6 (Automatic Entry Detail Return Entry) of this Appendix Three. At a minimum, the acknowledgment includes information from the following fields within the File Header and File Control Records:

Immediate Origin
Immediate Origin Name (if available)
File Creation Date
File Creation Time (if available)
File ID Modifier
File Entry/Addenda Count
Total Debit Entry Amount in File
Total Credit Entry Amount in File
File Batch Count
The acknowledgment also contains the date and time the file was processed by the BEFTN and, if the file was rejected, the reason for the rejection. If the file was not rejected, but one or more batches were rejected by the BEFTN, the acknowledgment will also contain the following information about each rejected batch:
Originating Bank Identification
Originating Bank Name (if available)
Company Name
Company Identification
Batch Number
Effective Entry Date
Batch Entry/Addenda Count
Total Debit Amount
Total Credit Amount
Reason for Batch Rejection
SECTION 3.2 File Level Reject Option
If the bank chooses the file level reject option, any condition which would cause a batch to be rejected will cause the entire file to be rejected. Automatic file rejections, as described in section 3.4 (Automatic File Rejection) of this Appendix Three, are not affected by this option.

SECTION 3.3 Batch Level Reject Option
If the bank chooses the batch level reject option, any condition that would cause only a batch to be rejected will allow the BEFTN to accept the file but to reject the erroneous batch as described in
section 3.5 (Automatic Batch Rejection) of this Appendix Three.
SECTION 3.4 Automatic File Rejections
The following error conditions will always cause the entire file to be rejected:

The file cannot be successfully read, e.g., data read failures, hardware/software error checks
indicated.
The file contains any “undefined” record type.
The File Header Record does not contain the number of a valid (a point defined on the BEFTN
routing table file).
The file is “out‐of‐balance,” i.e., one or more of the following conditions exist:
The summation of the counts, hash totals, and total amount on Company/Batch Control
Records does not agree with the File Control Record.
The actual number of blocks or batches in the file does not agree with the File Control Record
counts.
Mandatory fields in the File Header Record are not valid:
File ID Modifier is upper or lower case A‐Z or 0‐9.
Format Code is not 1.
The sequence of records in the file is incorrect.
The Immediate Origin, File Creation Date, File Creation Time, and File ID Modifier are equal to
that of a previously accepted file.
SECTION 3.5 Automatic Batch Rejection
The following error conditions will cause the batch to be rejected if batch level rejection has been specified, or will cause the entire file to be rejected if file level rejection has been specified:
The batch contains invalid characters (i.e., characters not specified in Appendix One, BEFTN
File Exchange Specifications).
Except for files coming from another EFT Operator, the OB Identification in the
Company/Batch Header Record is not the routing number of a valid OB.
The Service Class Code in a Company/Batch Header Record is other than a currently valid code.
The Trace Numbers on the file are not in ascending sequence within a batch.
The Transaction Codes in Entry Detail Records are invalid.
The Amount field in an Entry Detail Record is non‐numeric.
The sequence of records in the batch is incorrect.
The batch is “out‐of‐balance,” i.e., the counts, hash totals, or Takas in the Company/Batch
Control Records do not agree with the summation of the entries for the batch.
The Company Name is all spaces or all zeros.
The Company Entry Description is all spaces or all zeros.
The Company Identification is all spaces or all zeros.
The Standard Entry Class Code in the Company/Batch Header Record is other than a currently
valid code.
The Service Class Code in the Company/Batch Control Record is not the same as that in the
Company/Batch Header Record.
The first eight positions of the Trace Number in an Entry Detail Record are not the same as the
OB Routing Number in the corresponding (immediately preceding) Company/Batch Header Record.
The Transaction Code in an Entry Detail Record is not valid for the Service Class Code in the
Company/Batch Header Record. Either a debit Transaction Code is in a credit batch, or a credit Transaction Code is in a debit batch.
The Transaction Code in an Entry Detail Record is not valid for the Standard Entry Class Code in
the Company/Batch Header Record. For Standard Entry Class Code NOC or RET, the Transaction Code must be 21, 26, 31, or 36.
Return and non‐return transactions are in the same batch.
Return, dishonoured return, and/or contested dishonoured return transactions are in the
same batch.
The Batch Number in the Company/Batch Header Record is non‐numeric.
The Batch Number in the Company/Batch Control Record is non‐numeric.
The Batch Number in the Company/Batch Control Record is not the same as the Batch Number
in the Company/Batch Header Record.
SECTION 3.6 Automatic Entry Detail Return Entry
BEFTN uses return reason codes for the following error conditions.
(a) RB Not Qualified to Participate
(b) Improper Effective Entry Date
(c) Amount Field Error
(d) Addenda Error
(e) Mandatory Field Error
(f) Trace Number Error
(g) Routing Number Check Digit Error
(h) Non‐Settlement
(i) Return of Improper Debit Entry
(j) Return of Improper Credit Entry
These error conditions will never cause the entire file to be rejected but will always cause the entry detail record to be returned using an Addenda Record with an Addenda Type Code of “99”:

Creation of the resulting automated return entries shall be in accordance with the specifications in
Appendix Five (Return Entries).

APPENDIX FOUR
MINIMUM DESCRIPTION STANDARDS
These rules require each RB to send or make available to each Receiver specific minimum descriptive information concerning each credit or debit entry to the Receiver’s account. This descriptive information is as follows:
(a) Posting date to customer’s account
(b) Amount of the entry
(c) Company name
(d) Company entry description
(e) Type of account (e.g., checking)
(f) Number of the account
(g) Amount of any charges assessed against the account for electronic funds transfer services (h) Balances in the customer’s account at the beginning and at the close of the statement (i) Address and telephone number to be used for inquiries or notices of errors preceded by “Direct Inquiries To” or similar language (j) Company Descriptive Date (k) Individual Identification Number/ Identification Number

Terms used herein shall have the meanings set forth in Appendix Two (BEFTN Record Format Specifications) of these Rules.

APPENDIX FIVE
RETURN ENTRIES
Except as otherwise provided in Article Five, section 5.1 (Return of Entries) of these Rules, a RB may return entries for any reason, provided it uses an appropriate Return Reason Code as specified in this Appendix and, if it uses Return Reason Code R11 or R17, provided it specifies the reason for the return. If no appropriate Return Reason Code is specified in this Appendix Five, the RB shall use the code which most closely approximates the reason for return.
SECTION 5.1 Automated Return Entries
NOTE: Throughout this section, banks will always be designated by their original names. For example, the OB is the bank that initially prepared the original entry, and which will eventually have the Automated Return Entry delivered to it. The RB is the bank that was supposed to receive the original entry and will usually be preparing the Automated Return Entry. In some cases an Automated Return Entry may be prepared by the EFT Operator (BEFTN) if the entry cannot be delivered or if it contains an erroneous condition. When an Automated Return Entry is prepared, the original Company/Batch Header Record, the original Entry Detail Record, and the Company/Batch Control Record are copied for return to the Originator. (NOTE: This includes the original SEC code found in Field 51‐53 of the Company Batch Header record.) The SEC code “RET” is used by the BEFTN only. The Automated Return Entry is looked at as a new entry, generated because the original entry failed to accomplish its intended purpose. Thus, these entries should be assigned new batch and trace numbers, new identification numbers for the returning institution, appropriate transaction codes, and so on. The File Creation Date is of use to the OB when the entry is being returned by the BEFTN. Otherwise, this data element is for a file created outside the organization of the OB and the information is not helpful. The OB can determine if the date is from its own file by looking at Field 12 of the Company/Batch Header Record, which now carries the identification of the institution preparing the return entry. There is nothing required in the format that limits the number of Entry Detail Record/Addenda Record pairs to one for each batch. Multiple entry return entry batches certainly may be generated from one original batch.
SECTION 5.2 NonAutomated Return Entries
If the BEFTN agrees to accept non‐automated return entries, it must convert them to the automated format at the point of entry into the system. A return converted to the automated format may bear the Standard Entry Class “RET” when the original Standard Entry Class code is not available.
SECTION 5.3 Adjustment Entries
In compliance with Article Seven, section 7.7 (Adjustment Entries) of the Rules, adjustment entries are utilized by a RB when, upon receiving notice from its Receiver that a debit entry was, in whole or
part, unauthorized, the RB credits the amount of such entry to its Receiver’s account and returns the
erroneous entry to the OB.

Adjustment entries shall comply with the format and specifications for Return Entries in this
Appendix Five. In order to qualify as adjustment entries, returns must contain one of the Return
Reason Codes (either R07 or R9) designated as applicable to adjustment entries.
SECTION 5.4 Table of Return Reason Codes
Codes To Be Used by the RB for Return Entries
R01 ‐ Insufficient Funds
The available and/or cash reserve balance is not sufficient to cover the amount of the debit entry. R02 ‐ Account Closed A previously active account has been closed by action of the customer or the RB. R03 ‐ No Account/Unable to Locate Account The account number structure is valid and it passes the check digit validation, but the account number does not correspond to the individual identified in the entry, or the account number designated is not an open account. (Note: This Return Reason Code may not be used to return POP entries that do not contain an Individual Name.) R04 ‐ Invalid Account Number The account number structure is not valid. The entry may fail the check digit validation or may contain an incorrect number of digits. R05 ‐ Unauthorized Debit to Consumer Account Using Corporate SEC Code (Adjustment entries) A CCD or CTX debit entry was transmitted to a Consumer Account of the Receiver and was not authorized by the Receiver. The Receiver may request immediate credit from the RB for an unauthorized debit. The request must be made in writing within one hundred eighty calendar days after the RB sends or makes available to the Receiver information pertaining to that debit entry. The Receiver must also provide the RB with a written statement, pursuant to subsection 8.6.5 (Receiver’s Written Statement), that the debit entry was not authorized by the Receiver. For purposes of this code and related Operating Rules provisions, a debit entry was not authorized by a Receiver if (1) the authorization requirements of Article Two, subsection 2.1.2 (Receiver Authorization and Agreement) have not been met; (2) the debit entry was initiated in an amount greater than that authorized by the Receiver; or (3) the debit entry was initiated for settlement earlier than authorized by the Receiver. An unauthorized debit entry does not include a debit entry initiated with fraudulent intent by the Receiver or any person acting in concert with the Receiver. A RB using this return reason code must transmit the return entry by BEFTN deposit deadline for the return entry to be made available to the OB no later than the opening of business on the banking day following the one hundred eightieth calendar day following the Settlement Date of the original entry. R06 ‐ Returned per OB’s Request The OB has requested that the RB return the BEFTN entry. If the RB agrees to return the entry, the OB must indemnify the RB according to Article Five (Return, Adjustment, Correction, and Acknowledgment of Entries and Entry Information) of these Rules.

R07 ‐ Authorization Revoked by Customer (adjustment entries) The RB’s customer (the Receiver) has revoked the authorization previously provided to the Originator for this particular transaction. The Receiver may request immediate credit from the RB for an unauthorized debit. The request must be made in writing within one hundred eighty calendar days after the RB sends or makes available to the Receiver information pertaining to that debit entry. The Receiver must also provide the RB with a written statement that the authorization for the debit entry has been revoked by the Receiver. The RB must return the rescinded transaction to the BEFTN by its deposit deadline for the adjustment entry to be made available to the OB no later than the opening of business on the Banking day following the one hundred eightieth calendar day following the Settlement Date of the original entry. This code and related Operating Rule provisions apply to Consumer entries only. R08 ‐ Payment Stopped The Receiver of a debit transaction has the right to stop payment on any specific BEFTN debit. A stop payment request should be handled in accordance with the provisions of Article Seven (Recall, Stop Payment, Re‐credit, and Adjustment) of these Rules. The RB should verify the Receiver’s intent when a request for stop payment is made to ensure this is not intended to be a revocation of authorization (R07). A stop payment order shall remain in effect until the earliest of the following occurs: a lapse of six months from the date of the stop payment order, payment of the debit entry has been stopped, or the Receiver withdraws the stop payment order. R09 ‐ Uncollected Funds Sufficient book or ledger balance exists to satisfy the amount of the transaction, but the amount of transactions in the process of collection (i.e., uncollected checks) brings the available and/or cash reserve balance below the Taka value of the debit entry. R10 ‐ Customer Advises Not Authorized For entries to Consumer Accounts that the Originator of a given transaction has not been authorized to debit his account, the Receiver may request immediate credit from the RB for an unauthorized debit. The request must be made in writing within one hundred eighty calendar days after the RB sends or makes available to the Receiver information pertaining to that debit entry. The Receiver must also provide the RB with a written statement, pursuant to subsection 7.6.4 (Receiver’s Written Statement), that the debit entry was not authorized by the Receiver. For purposes of this code and related Operating Rules provisions, a debit entry was not authorized by the Receiver if (1) the authorization requirements of Article Two, subsection 2.1.2 (Receiver Authorization and Agreement) have not been met; (2) the debit entry was initiated in an amount greater than that authorized by the Receiver; or (3) the debit entry was initiated for settlement earlier than authorized by the Receiver. An unauthorized debit entry does not
include a debit entry initiated with fraudulent intent by the Receiver or any person acting in concert with the Receiver. The RB must return the rescinded transaction to the BEFTN by its deposit deadline for the adjustment entry to be made available to the OB no later than the opening of business on the Banking day following the one hundred eightieth calendar day following the Settlement Date of the original entry. This code and related Operating Rule provisions apply to Consumer entries only.

R11 ‐ Reserved
R12 ‐ Branch Sold to Another Bank
A Bank may continue to receive entries destined for an account at a branch that has been sold to another Bank. Because the RB no longer maintains the account and is unable to post the entry, it should return the entry to the OB. R14 ‐ Representative Payee Deceased or Unable to Continue in that Capacity The representative payee is a person or institution authorized to accept entries on behalf of one or more other persons, such as legally incapacitated adults or minor children. The representative payee is either deceased or unable to continue in that capacity. The beneficiary is not deceased. R15 ‐ Beneficiary or Account Holder (Other than a Representative Payee) Deceased (1) The beneficiary is the person entitled to the benefits and is deceased. The beneficiary may or may not be the account holder; or (2) The account holder (acting in a non‐representative payee capacity) is an owner of the account and is deceased. R16 ‐ Account Frozen The funds in the account are unavailable due to specific action taken by the RB or by legal action. R17 ‐ File Record Edit Criteria (Specify) Some fields that are not edited by the BEFTN are edited by the RB. If the entry cannot be processed by the RB, the field(s) causing the processing error must be identified in the addenda record information field of the return. R20 ‐ Non‐Transaction Account The BEFTN entry destined for a non‐transaction account would include either an account against which transactions are prohibited or limited. R21 ‐ Invalid Company Identification The identification number used in the Company Identification Field is not valid. This Return Reason Code will normally be used on CIE transactions. R22 ‐ Invalid Individual ID Number The Receiver has indicated to the RB that the number with which the Originator was identified is not correct. R23 ‐ Credit Entry Refused by Receiver The Receiver may return a credit entry because one of the following conditions exists: (1) a minimum amount required by the Receiver has not been remitted; (2) the exact amount required has not been remitted; (3) the account is subject to litigation and the Receiver will not accept the transaction; (4) acceptance of the transaction results in an overpayment; (5) the Originator is not known by the Receiver; or (6) the Receiver has not authorized this credit entry to this account. R24 ‐ Duplicate Entry

The RB has received what appears to be a duplicate entry; i.e., the trace number, date, Taka amount and/or other data matches another transaction. This code should be used with extreme care. The RB should be aware that if a file has been duplicated, the Originator may have already generated a reversal transaction to handle the situation. R29 ‐ Corporate Customer Advises Not Authorized The RB has been notified by the Receiver (non‐consumer) that a specific transaction has not been authorized by the Receiver. Codes to be Used by the OB for Automated Dishonored Return Entries:
R61 ‐ Misrouted Return
The bank preparing the return entry (the RB of the original entry) has placed the incorrect Routing Number in the RB Identification field including Check Digit, of the Entry Detail Record). R67 ‐ Duplicate Return The OB has received more than one return for the same entry. R68 ‐ Untimely Return The return entry has not been sent within the timeframe established by these rules. R69 ‐ Field Error(s) One or more of the following fields – Bank Account Number, Original Entry Trace Number, Amount, Individual Identification Number/Identification Number, Company Identification, and/or Transaction Code – are incorrect. The OB must insert the appropriate code(s) from the list below, separated by an asterisk (*), within the Addenda Information Field of the Addenda Record Format for Automated Dishonored Returns to indicate the field(s) in which the errors occur:
01 Return Contains Incorrect Bank Account Number 02 Return Contains Incorrect Original Entry Trace Number 03 Return Contains Incorrect Dollar Amount 04 Return Contains Incorrect Individual Identification Number/Identification Number 05 Return Contains Incorrect Transaction Code 06 Return Contains Incorrect Company Identification Number 07 Return Contains an Invalid Effective Entry Date R70 ‐ Permissible Return Entry Not Accepted/Return Not Requested by OB The OB has received a return entry identified by the RB as being returned with the permission of, or at the request of, the OB, but the OB has not agreed to accept the entry or has not requested the return of the entry. This code may be used only to dishonor return entries containing return reason codes R06 and R31. Codes to be used by the RB for Automated Contested Dishonored Return Entries:
R71 ‐ Misrouted Dishonored Return
The financial institution preparing the dishonored return entry (the OB of the original entry) has placed the incorrect Routing Number in the RB Identification field including Check Digit, of the Entry Detail Record). R72 ‐ Untimely Dishonored Return The dishonored return entry has not been sent within the designated timeframe.

R73 ‐ Timely Original Return
The RB is certifying that the original return entry was sent within the timeframe designated in these rules. R74 ‐ Corrected Return The RB is correcting a previous return entry that was dishonored using Return Reason Code R69 (d (Field Errors) because it contained incomplete or incorrect information. Corrected data will be in its defined position in the Company/Batch Header, Entry Detail Record, or Addenda Record, as follows:

Original Entry Trace is in the Return Addenda Record,
Dollar amount is in the Entry Detail Record;
Individual Identification Number/Identification Number is in the Entry
Detail Record, for CCD, CTX, PPD;
Company Identification is in the Company/Batch Header Record
Transaction Code is in the Entry Detail Record
Bank Account Number is in the Entry Detail Record
R75 ‐ Original Return Not a Duplicate
The original return entry was not a duplicate of an entry previously returned by the RB. This code may be used by the RB to contest an entry dishonored by the OB using Return Reason Code R67 (Duplicate Return). R76 ‐ No Errors Found The original return entry did not contain the errors indicated by the OB in the Dishonored Return Entry bearing Return Reason Code R69 (Field Errors).

BEFTN Operator Returns
R13 RB Not Qualified to Participate
R18 Improper Effective Entry Date
R19 Amount Field Error
R25 Addenda Error
R26 Mandatory Field Error
R27 Trace Number Error
R28 Routing Number Check Digit Error
R30 RB Not Participant in Check Truncation Program R32 RB Non‐Settlement R34 Return of Improper Debit Entry R35 Return of Improper Credit Entry
SECTION 5.5 Record Formats for Automated and Converted Return Entries
Unless otherwise noted in the following record formats, the field contents for automated and converted return entries will match the field contents of the original entries. [See Appendix Two (BEFTN Record Format Specifications) for the File Header, Company/Batch Control and File Control Record formats.]
5.5.1 Corporate Entry Detail Record Format for Returns
Returns ‐ Corporate Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
TOTAL
AMOUNT
IDENTIFICATION
NUMBER
NUMBER OF
ADDENDA
RECORDS
RECEIVING
COMPANY
NAME/ID
NUMBER
RESERVED DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O M R N/A R M M
Contents ‘6’ 1
Numeric
TTTTAAAA
Numeric Alphanumeric
$$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric ‘1’ 4 Numeric

Length 1 2 8 1 17 12 15 4 16 2 2 1 15
NOTE: For Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the original entry, unless otherwise noted.

Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under
currently assigned “Code Values” in Appendix Two).
Changed to the Routing Number of the institution receiving the Return Entry (i.e., the OB of
the original entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number contained in positions 04‐11.
Changed to the Trace Number assigned by the institution.
5.5.2 Entry Detail Record Format for Returns
Returns ‐ Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION/
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
AMOUNT INDIVIDUAL
IDENTIFICATION NUMBER/
IDENTIFICATION NUMBER/
CHECK SERIAL NUMBER
INDIVIDUAL NAME/
RECEIVING COMPANY
NAME
DISCRETIONARY DATA/
CARD TRANSACTION
TYPE CODE
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O M R/M
Contents ‘6’ 1
Numeric
TTTTAAAA
Numeric Alphanumeric
$$$$$$$$¢¢
Alphanumeric
Alphanumeric
Alphanumeric
‘1’ 7
Numeric
Length 1 2 8 1 17 12 15 22 2 1 15
NOTE: For Return Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under
currently assigned “Code Values” in Appendix Two.)
Changed to the Routing Number of the institution receiving the Return Entry (i.e., the OB of
the original entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number contained in positions 04‐11.
For CIE entries, positions 40‐54 are used for a 15‐character Individual Name, and positions
55‐76 are used for a 22‐character Individual Identification Number.
Changed to the Trace Number assigned by the institution preparing the Automated Return
Entry.

5.5.4 Addenda Record Format for Returns
Returns ‐ Addenda Record
FIELD 1 2 3 4 5 6 7 8
DATA
ELEMENT
NAME
RECORD TYPE
CODE
ADDENDA TYPE
CODE
RETURN REASON
CODE
ORIGINAL ENTRY
TRACE NUMBER
DATE OF DEATH ORIGINAL RECEIVING BANK IDENTIFICATION ADDENDA INFORMATION TRACE NUMBER Field Inclusion Requirement M O R O M Contents ‘7’ ‘99’ Alphanumeric 1 Numeric YYMMDD TTTTAAAA Alphanumeric Numeric

Length 1 2 3 15 6 8 44 15

Copy data from positions 80‐94 of the Entry Detail Record
To be used only with Return Code R14 or R15.
Copy data from positions 04‐11 of the original Entry Detail Record.
SECTION 5.6 Dishonoured Return Entries by BEFTN
The following specifications apply to Dishonoured Return Entries:

Each Dishonoured Return Entry initiated by an OB must be in the automated format and
sequence set forth in this Appendix Five.
Terms used in the format shall have the meanings set forth in Appendix Two (BEFTN Record
Format Specifications).
The initiation of an Automated Dishonoured Return Entry with Return Reason Code R68
constitutes a certification by the OB that the return was untimely and a loss was suffered.
The Company/Batch Header Record, Entry Detail Record, and Addenda Record format as set
forth in this Appendix Five must be used.
The Transaction Code used in the Entry Detail Record must be 21 or 26 for Demand Accounts, 31
or 36 for Savings Accounts, 41 or 46 for General Ledger Accounts, or 51 or 56 for Loan Accounts.
Addenda Type Code “99” must be used to indicate that the addenda record contains automated
return information.
The following fields of the Addenda Record must be filled when originating an Automated
Dishonoured Return Entry:
Positions 39 ‐ 53 containing the Return Trace Number
Positions 54 ‐ 56 containing the Return Settlement Date
Positions 57 ‐ 58 containing the Return Reason Code
5.6.1 Company/Batch Header Record Format for Automated Dishonoured Returns
Dishonoured Returns ‐ Company/Batch Header Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE COMPANY NAME COMPANY DISCRETIONARY DATA COMPANY IDENTIFICATION STANDARD ENTRY CLASS CODE COMPANY ENTRY DESCRIPTION COMPANY DESCRIPTIVE DATE EFFECTIVE ENTRY DATE SETTLEMENT DATE (JULIAN) ORIGINATOR STATUS CODE ORIGINATING BANK IDENTIFICATION BATCH NUMBER Field Inclusion Requirement M O M O R Inserted by EFT Operator M Contents ‘5’ Numeric Alphanumeric YYMMDD Numeric 1 Alphanumeric TTTTAAAA Numeric Length 1 3 16 20 10 3 10 6 6 3 1 8 7 NOTE: For Dishonoured Return Entries, each field of the Company/Batch Header Record remains unchanged from the Return Entry, unless otherwise noted.

Changed to reflect the Originator Status Code of the institution initiating the Dishonoured
Return Entry (i.e., the RB of the Return Entry).
Changed to reflect the Routing Number of the institution initiating the Dishonoured Return
Entry (i.e., the RB of the Return Entry).
Changed to a Batch Number assigned by the institution preparing the Dishonoured Return
Entry.

5.6.2 Corporate Entry Detail Record for Automated Dishonoured Returns
Dishonoured Returns ‐ Corporate Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RECEIVING BANK IDENTIFICATION CHECK DIGIT BANK ACCOUNT NUMBER TOTAL AMOUNT IDENTIFICATION NUMBER NUMBER OF ADDENDA RECORDS RECEIVING COMPANY NAME/ID NUMBER RESERVED DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O M R N/A R M M Contents ‘6’ Numeric 1 TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric ‘1’ 3 Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 NOTE: For Dishonoured Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the Return entry, unless otherwise noted.

Changed to the Routing Number of the institution receiving the Dishonoured Return Entry
(i.e., the OB of the Return Entry).
Changed to the Check Digit calculated according to BEFTN Standards and based on the
Routing Number contained in positions 04‐11.
Changed to the Trace Number assigned by the institution preparing the Dishonoured Return
Entry (i.e., the RB of the Return Entry).
5.6.3 Entry Detail Record Format for Automated Dishonoured Returns
Dishonoured Returns ‐ Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RECEIVING BANK
IDENTIFICATION/
OGO IDENTIFICATION
CHECK
DIGIT
BANK
ACCOUNT
NUMBER
AMOUNT INDIVIDUAL
IDENTIFICATION NUMBER/
IDENTIFICATION NUMBER/
CHECK SERIAL NUMBER
INDIVIDUAL NAME/
RECEIVING COMPANY
NAME
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O M R M M
Contents ‘6’ Numeric 1
TTTTAAAA
Numeric
Alphanumeric $$$$$$$$¢¢ Alphanumeric 3
Alphanumeric
Alphanumeric ‘1’ 4
Numeric
Length 1 2 8 1 17 12 15 22 2 1 15
NOTE: For Dishonoured Return Entries, each field of the Entry Detail Record remains unchanged from the Return Entry, unless otherwise noted.
Changed to the Routing Number of the institution receiving the Dishonoured Return Entry
(i.e., the OB of the Return Entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number contained in positions 04‐11.
Changed to the Trace Number assigned by the institution preparing the Dishonoured Return
Entry (i.e., the RB of the Return Entry).

5.6.5 Addenda Record Format for Automated Dishonoured Returns
Dishonoured Returns ‐ Addenda Record
FIELD 1 2 3 4 5 6 7 8 9 10 11 12
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
ADDENDA TYPE
CODE
DISHONORED RETURN
REASON CODE
ORIGINAL
ENTRY TRACE
NUMBER RESERVED
ORIGINAL
RECEIVING BANK
IDENTIFICATION RESERVED
RETURN TRACE
NUMBER
RETURN
SETTLEMENT
DATE
RETURN
REASON
CODE
ADDENDA
INFORMATION
TRACE
NUMBER
Field
Inclusion
Requirement M N/A R N/A M
Contents
‘7’ ‘99’ Alphanumeric
Numeric Blank
TTTTAAAA Blank Numeric Numeric Alphanumeric
Blank
[Alphanumeric]
Numeric
Length 1 2 3 15 6 8 3 15 3 2 21 15

Copy data from positions 7‐21 of the Addenda Record of the return entry.
Copy data from positions 28‐35 of the Addenda Record of the return entry.
The Addenda Information Field of a Dishonoured Return Entry is a mandatory field when the
Dishonoured Return bears Return Reason Code R69 (Field Errors). When using Return Reason Code R69, the OB must insert the appropriate code(s) from the list below, separated by an asterisk (), within the Addenda Information Field of the Addenda Record Format for Automated Dishonoured Returns to indicate the field(s) in which the errors occur:
01 Return Contains Incorrect Account Number
02 Return Contains Incorrect Original Entry Trace Number 03 Return Contains Incorrect Taka Amount 04 Return Contains Incorrect Individual Identification Number/Identification Number 05 Return Contains Incorrect Transaction Code 06 Return Contains Incorrect Company Identification Number 07 Return Contains an Invalid Effective Entry Date For example: 0103*06
For Automated Dishonoured Returns, changed to reflect the new Trace Number found in
positions of the Entry Detail Record or Corporate Entry Detail Record.
SECTION 5.7 Contested Dishonoured BEFTN Return Entries
5.7.1 Automated Contested Dishonoured Return Entries
Each Automated Contested Dishonoured Return Entry initiated by a RB must be in the format and sequence set forth in this Appendix Five.

Terms used in the format shall have the meanings set forth in Appendix Two (BEFTN Record
Format Specifications).
The initiation of an Automated Contested Dishonoured Return Entry constitutes a certification
by the RB that the entry was returned in accordance with these Rules.
The Company/Batch Header Record, Entry Detail Record, and Addenda Record format as set
forth in this Appendix Five must be used.
The Transaction Code used in the Entry Detail Record must be either 21 or 26 for Demand
Accounts, 31 or 36 for Savings Accounts or 51 or 56 for Loan Accounts.
Addenda Type Code “99” must be used to indicate that the addenda record contains automated
return information.
The following fields of the Addenda Record must be filled when originating an Automated
Contested Dishonoured Return Entry:
Date Original Entry Returned
Original Settlement Date (Julian Date)
Return Trace Number
Return Settlement Date
Return Reason Code
Dishonoured Return trace number
Dishonoured Return Settlement Date
Dishonoured Return Reason Code
5.7.2 NonAutomated Contested Dishonoured Return Entries
An EFT Operator that agrees to accept non‐automated Contested Dishonoured Return Entries must convert them to an automated format at the point of entry into the system.
5.7.3 Corrected Return Entries
A RB may generate a Corrected Return by creating a Contested Dishonoured Return with reason code “R74.” The format is the same as that for other Contested Dishonoured Returns. The corrected data is in its prescribed location in the Company/Batch Header Record (Company ID), Entry Detail Record (Taka Amount, Individual ID/Identification Number), or Return Addenda Record (Original Entry Trace Number).
5.7.4 Company/Batch Header Record Format for Automated Contested Dishonoured
Returns
Contested Dishonoured Return ‐ Company/Batch Header Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE COMPANY NAME COMPANY DISCRETIONARY DATA COMPANY IDENTIFICATION STANDARD ENTRY CLASS CODE COMPANY ENTRY DESCRIPTION COMPANY DESCRIPTIVE DATE EFFECTIVE ENTRY DATE SETTLEMENT DATE (JULIAN) ORIGINATOR STATUS CODE ORIGINATING BANK IDENTIFICATION BATCH NUMBER Field Inclusion Requirement M O M O R Inserted by EFT Operator M Contents ‘5’ Numeric Alphanumeric YYMMDD Numeric 1 Alphanumeric TTTTAAAA Numeric Length 1 3 16 20 10 3 10 6 6 3 1 8 7 NOTE: For Contested Dishonoured Return Entries, each field of the Company/Batch Header Record remains unchanged from the Dishonoured Return Entry, unless otherwise noted.

Changed to reflect the Originator Status Code of the institution initiating the Contested
Dishonoured Return Entry (i.e., the RB of the Dishonoured Return Entry).
Changed to reflect the Routing Number of the institution initiating the Contested
Dishonoured Return Entry (i.e., the RB of the Dishonoured Return Entry).
Changed to a Batch Number assigned by the institution preparing the Contested
Dishonoured Return Entry.

5.7.5 Corporate Entry Detail Record Format for Automated Contested Dishonoured
Returns
Contested Dishonoured Returns ‐ Corporate Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RECEIVING BANK IDENTIFICATION CHECK DIGIT BANK ACCOUNT NUMBER TOTAL AMOUNT IDENTIFICATION NUMBER NUMBER OF ADDENDA RECORDS RECEIVING COMPANY NAME/ID NUMBER RESERVED DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O M R N/A R M M Contents ‘6’ Numeric 1 TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric ‘1’ 3 Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 NOTE: For Contested Dishonoured Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the Dishonoured Return entry, unless otherwise noted.

Changed to the Routing Number of the institution receiving the Contested Dishonoured
Return Entry (i.e., the OB of the Dishonoured Return Entry).
Changed to the Check Digit calculated according to BEFTN Standards and based on the
Routing Number .
Changed to the Trace Number assigned by the institution preparing the Contested
Dishonoured Return Entry (i.e., the RB of the Dishonoured Return Entry).
5.7.6 Entry Detail Record Format for Automated Contested Dishonoured Returns
Contested Dishonoured Returns ‐ Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RECEIVING BANK IDENTIFICATION/ OGO IDENTIFICATION CHECK DIGIT BANK ACCOUNT NUMBER AMOUNT INDIVIDUAL IDENTIFICATION NUMBER/ IDENTIFICATION NUMBER/ CHECK SERIAL NUMBER INDIVIDUAL NAME/ RECEIVING COMPANY NAME DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O M R M M Contents ‘6’ Numeric 1 TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric 3 Alphanumeric Alphanumeric ‘1’ 4 Numeric Length 1 2 8 1 17 12 15 22 2 1 15 NOTE: For Contested Dishonoured Return Entries, each field of the Entry Detail Record remains unchanged from the Dishonoured Return Entry, unless otherwise noted.
Changed to the Routing Number of the institution receiving the Contested Dishonoured
Return Entry (i.e., the OB of the Dishonoured Return Entry).
Changed to the Check Digit calculated according to BEFTN Standards and based on the
Routing Number.
Changed to the Trace Number assigned by the institution preparing the Contested
Dishonoured Return Entry (i.e., the RB of the Dishonoured Return Entry).
5.7.7 Addenda Record Format for Automated Contested Dishonoured Returns

Contested Dishonoured Returns ‐ Addenda Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE CONTESTED DISHONORED RETURN REASON CODE ORIGINAL ENTRY TRACE NUMBER DATE ORIGINAL ENTRY RETURNED ORIGINAL RECEIVING BANK IDENTIFICATION ORIGINAL SETTLEMENT DATE (JULIAN) RETURN TRACE NUMBER RETURN SETTLEMENT DATE RETURN REASON CODE DISHONORED RETURN TRACE NUMBER DISHONORED RETURN SETTLEMENT DATE DISHONORED RETURN REASON CODE RESERVED TRACE NUMBER Field Inclusion Requirement M O R M N/A M Contents ‘7’ ‘99’ Alphanumeric 1 Numeric YYMMDD TTTTAAAA Numeric Alphanumeric Numeric Numeric Alphanumeric Blank 4 Numeric Length 1 2 3 15 6 8 3 15 3 2 15 3 2 1 15

Copy data from Original Entry Trace Number of the Addenda Record of the Dishonoured
Return Entry.
Mandatory only if Contested Dishonoured Return Reason Code is R73.
Copy data from positions Original Receiving Bank of the Addenda Record of the Dishonoured
Return Entry.
For Automated Contested Dishonoured Returns, changed to reflect the new Trace Number
found in the Entry Detail Record or Corporate Entry Detail Record.

APPENDIX SIX
NOTIFICATION OF CHANGE
A Notification of Change is created by a RB to notify the OB that previously valid information contained in a posted entry has become outdated or that information contained in a prenotification is erroneous and should be changed. A Notification of Change is inapplicable to Shared Network Transactions when the RB is also the card issuer.
SECTION 6.1 Automated Notification of Change
An Automated Notification of Change must comply with the following specifications:

A zero amount must be indicated.
Addenda Type Code 98 must be used to indicate that the Addenda Record contains automated
change information.
Field 3 of the Addenda Record must contain the appropriate code indicating the information to
be changed, in accordance with the Table of Change Codes set forth in this Appendix Six. Field 7 of the Addenda Record must contain the change (correction) information corresponding to the change code used, in accordance with the Table of Change Codes set forth in this Appendix Six.
The Standard Entry Class Code “COR” must be used to denote a batch containing automated
change information.
Company/Batch Header Record, Entry Detail Record, and Addenda Record formats as set forth in
this section must be used.
The Transaction Code, Entry Detail Record must be either 21, 26, 31, 36, 41, 46, 51, or 56.
SECTION 6.2 NonAutomated Notification of Change
An EFT Operator that agrees to accept non‐automated Notification of Change entries must convert them to the automated format at the point of entry into the system.
SECTION 6.3 Refused BEFTN Notification of Change
A Refused BEFTN Notification of Change is created by an OB to refuse a Notification of Change entry containing incorrect or incomplete information. The Refused Notification of Change must be in automated form. Each automated Refused Notification of Change entry of an OB must be in the format and sequence set forth in this Appendix Six and must contain the reason(s) for the refusal of the Notification of Change Entry.
SECTION 6.4 Minimum Description Standards for Notifications of Change and Corrected
Notifications of Change
An OB must, at a minimum, provide to each of its Originators the following information, with respect to each Notification of Change or Corrected Notification of Change entry received by the OB, within two Banking days of the Settlement Date of the NOC or Corrected NOC entry:
(a) Company Name;
(b) Company Identification;
(c) Company Entry Description;

(d) Effective Entry Date;
(e) Bank Account Number;
(f) Individual Name/Receiving Company Name;
(g) Individual Identification Number/
(h) Identification Number;
(i) Change Code;
(j) Original Entry Trace Number;
(k) Original Receiving Bank Identification; and (l) Corrected Data.
SECTION 6.5 Table of Change Codes
Table of Change Codes
Code Meaning
C01 Incorrect Bank Account Number
Correct BANK Account Number appears in first (left justification) 17 positions of the Corrected Data Field. Example: This code would also be used when an Account Number is incorrectly formatted. C02 Incorrect Routing Number Correct Routing Number (including Check Digit) appears in first nine positions of the Corrected Data Field. Example: Due to merger or consolidation, a once valid Routing Number must be changed. C03 Incorrect Routing Number and Incorrect Bank Account Number Correct Routing Number (including Check Digit) appears in first nine positions of the Corrected Data Field—correct BANK Account Number appears in the 13th through 29th position of same field with a space in the 9th, 11th, and 12th position. Example: Due to merger or consolidation, a once valid Routing Number must be changed, and in most instances this change will cause a change to the account numbering structure. C04 Incorrect Individual Name/Receiving Company Name Correct Individual Name/Receiving Company Name appears in first 22 positions of the Corrected Data Field. C05 Incorrect Transaction Code Correct Transaction Code appears in first two positions of the Corrected Data Field. Example: An item which the RB determines should be posted to their Demand Deposit Account (DDA) System contains a Savings Transaction Code. C06 Incorrect Bank Account Number and Incorrect Transaction Code Correct BANK Account Number appears in the first (left justification) 17 positions of the Corrected Data Field—correct Transaction Code appears in the 21st and 22nd positions of the same field with spaces in the 18th , 19th , and 20th positions.

Example: An entry posting to a savings account should actually be going to a demand account or vice versa, and the account number is also incorrect. C07 Incorrect Routing Number, Incorrect Bank Account Number, and Incorrect Transaction Code Correct Routing Number (including Check Digit) appears in the first nine positions of the Corrected Data Field—correct BANK Account Number appears in the 9th through 26th positions of the same field—and correct Transaction Code appears in the 27th and 28th positions of the same field. Example: An entry posting to a savings account should actually be going to a demand account or vice versa, and the routing number and account number are also incorrect. C08 Reserved C09 Incorrect Individual Identification Number Correct number appears in first 22 positions of the Corrected Data Field. Example: Individual’s Identification Number within the Company is incorrect, either on initial input or through merger or consolidation. C13 Addenda Format Error Information in the Entry Detail Record was correct and the entry was able to be processed and posted by the RB. However, information found in the Addenda Record was unclear or was formatted incorrectly. Example: A Corporate entry is received with an “05” Addenda Type Code, but the addenda information does not contain payment related ANSI ASC X12 data segments or endorsed Banking conventions.
Table of Change Codes for Refused Notification of Change Entries
Change codes C61‐C69 are only to be used when refusing a Notification of Change:
C61 Misrouted Notification of Change C62 Incorrect Trace Number C63 Incorrect Company Identification Number C64 Incorrect Individual Identification Number/Identification Number C65 Incorrectly Formatted Corrected Data C66 Incorrect Discretionary Data C67 Routing Number Not From Original Entry Detail Record C68 Bank Account Number Not From Original Entry Detail Record C69 Incorrect Transaction Code

The Refused Notification of Change process can only be used with the above Reason Codes (C61 ‐ C69). If a reason other than those listed (C61 ‐ C69) exists, the item should be handled outside of the Refused Notification of Change process. (This limitation applies only to the Refused Notification of Change process.)

SECTION 6.6 Record Formats for Automated and Converted Notifications of Change
Unless otherwise noted in the following record formats, the field contents for automated and converted notifications of change entries will match the field contents of the original entries. (See
Appendix Two (BEFTN Record Format Specifications) for the File Header, Company/Batch Control
and File Control Record formats.)
6.6.1 Company/Batch Header Record Format for Notifications of Change
Notification of Change ‐ Company/Batch Header Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE COMPANY NAME COMPANY DISCRETIONARY DATA COMPANY IDENTIFICATION STANDARD ENTRY CLASS CODE COMPANY ENTRY DESCRIPTION COMPANY DESCRIPTIVE DATE EFFECTIVE ENTRY DATE SETTLEMENT DATE (JULIAN) ORIGINATOR STATUS CODE ORIGINATING BANK IDENTIFICATION BATCH NUMBER Field Inclusion Requirement M O M O R Inserted by EFT Operator M Contents ‘5’ Numeric Alphanumeric 1 Alphanumeric Alphanumeric Alphanumeric YYMMDD Numeric 3 Alphanumeric TTTTAAAA Numeric Length 1 3 16 20 10 3 10 6 6 3 1 8 7 NOTE: For Notification of Change Entries, each field of the Company/Batch Header Record remains unchanged from the original entry, unless otherwise noted.

Contains ‘COR’ for all Notification of Change Entries.
May contain the identification of the EFT Operator (BEFTN) converting the entry.
Changed to reflect the Originator Status Code of the institution initiating the Notification of
Change Entry (i.e., the RB of the original entry).
Changed to reflect the Routing Number of the institution initiating the Notification of
Change Entry.
Changed to the batch number assigned by the institution preparing the Automated
Notification of Change Entry.
6.6.2 Corporate Entry Detail Record Format for Notifications of Change
Notification of Change ‐ Corporate Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RB IDENTIFICATION CHECK DIGIT ACCOUNT NUMBER TOTAL AMOUNT IDENTIFICATION NUMBER NUMBER OF ADDENDA RECORDS RECEIVING COMPANY NAME/ID NUMBER RESERVED DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O N/A R N/A O M M Contents ‘6’ 1 Numeric TTTTAAAA Numeric Alphanumeric 4 0000000000 Alphanumeric Blank Alphanumeric Blank Alphanumeric ‘1’ 5 Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 NOTE: For Notification of Change Entries, each field of the Corporate Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
Changed to the appropriate Transaction Code. (See Transaction Codes under currently
assigned “Code Values” in Appendix Two.)
Changed to the Routing Number of the institution receiving the Notification of Change Entry
(i.e., the OB of the original entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number contained in positions 04‐11.
This field must be zero filled.
Changed to the Trace Number assigned by the institution preparing the Automated
Notification of Change Entry.
6.6.3 Entry Detail Record Format for Notifications of Change

Notification of Change ‐ Entry Detail Record
FIELD 1 2 3 4 5 6 7 8 9 10 11
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
TRANSACTION
CODE
RB
IDENTIFICATION
CHECK
DIGIT
Bank
ACCOUNT
NUMBER
AMOUNT INDIVIDUAL
IDENTIFICATION
NUMBER/
IDENTIFICATION NUMBER
INDIVIDUAL NAME/
RECEIVING COMPANY
NAME
DISCRETIONARY
DATA
ADDENDA
RECORD
INDICATOR
TRACE
NUMBER
Field
Inclusion
Requirement
M R M O R O M M
Contents ‘6’ 1
Numeric
TTTTAAAA
Numeric
Alphanumeric 4
0000000000
Alphanumeric
Alphanumeric
Alphanumeric ‘1’ 6
Numeric
Length 1 2 8 1 17 12 15 22 2 1 15
NOTE: For Notification of Change Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.

Changed to the appropriate Notification of Change Entry Transaction Code. (See Transaction
Codes under currently assigned “Code Values” in Appendix Two.)
Changed to the Routing Number of the institution receiving the Notification of Change Entry
(i.e., the OB of the original entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number.
This field must be zero filled.
For CIE entries, 15 characters are used for Individual Name, and 22 characters are used for
Individual Identification Number.
Changed to the Trace Number assigned by the institution preparing the Automated
Notification of Change Entry.
6.6.4 Addenda Record Format for Notifications of Change

Notification of Change ‐ Addenda Record
FIELD 1 2 3 4 5 6 7 8 9
DATA
ELEMENT
NAME
RECORD
TYPE
CODE
ADDENDA
TYPE
CODE
CHANGE
CODE
ORIGINAL ENTRY
TRACE NUMBER
RESERVED ORIGINAL RECEIVING
BANK IDENTIFICATION
CORRECTED
DATA
RESERVED TRACE
NUMBER
Field
Inclusion
Requirement
M N/A R M N/A M
Contents ‘7’ ‘98’ Alphanumeric 1
Numeric
Blank 2
TTTTAAAA
Alphanumeric Blank Numeric
Length 1 2 3 15 6 8 29 15 15

Copy Trace Number from the Entry Detail Record or Corporate Entry Detail Record.
Copy RB Routing Number of the original Entry Detail Record.

6.6.5 Company/Batch Header Record Format for Automated Refused Notifications of
Change

Refused Notification of Change ‐ Company/Batch Header Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE SERVICE CLASS CODE COMPANY NAME COMPANY DISCRETIONARY DATA COMPANY IDENTIFICATION STANDARD ENTRY CLASS CODE COMPANY ENTRY DESCRIPTION COMPANY DESCRIPTIVE DATE EFFECTIVE ENTRY DATE SETTLEMENT DATE (JULIAN) ORIGINATOR STATUS CODE ORIGINATING BANK IDENTIFICATION BATCH NUMBER Field Inclusion Requirement M O M O R Inserted by EFT Operator M Contents ‘5’ Numeric Alphanumeric YYMMDD Numeric 1 Alphanumeric TTTTAAAA Numeric Length 1 3 16 20 10 3 10 6 6 3 1 8 7 NOTE: For Refused NOC Entries, each field of the Company/Batch Header Record remains unchanged from the NOC entry, unless otherwise noted.

Changed to reflect the Originator Status Code of the institution initiating the Refused NOC
Entry (i.e., the RB of the NOC Entry).
Changed to reflect the Routing Number of the institution initiating the Refused NOC Entry
(i.e., the RB of the NOC Entry).
Changed to the Batch Number assigned by the institution preparing the Refused NOC Entry.
6.6.6 Corporate Entry Detail Record Format for Automated Refused Notifications of
Change

Refused Notification of Change ‐ Corporate Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RB IDENTIFICATION CHECK DIGIT BANK ACCOUNT NUMBER TOTAL AMOUNT IDENTIFICATION NUMBER NUMBER OF ADDENDA RECORDS RECEIVING COMPANY NAME/ID NUMBER RESERVED DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O M R N/A R M M Contents ‘6’ Numeric 1 TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric Numeric Alphanumeric Blank Alphanumeric ‘1’ 3 Numeric Length 1 2 8 1 17 12 15 4 16 2 2 1 15 NOTE: For Refused NOC Entries, each field of the Corporate Entry Detail Record remains unchanged from the NOC entry, unless otherwise noted.

Changed to the Routing Number of the institution receiving the Refused NOC Entry (i.e., the
OB of the NOC Entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number.
Changed to the Trace Number assigned by the institution preparing the Refused NOC Entry
(i.e., the RB of the NOC entry).

6.6.7 Entry Detail Record Format for Automated Refused Notifications of Change

Refused Notification of Change ‐ Entry Detail Record FIELD 1 2 3 4 5 6 7 8 9 10 11 DATA ELEMENT NAME RECORD TYPE CODE TRANSACTION CODE RB IDENTIFICATION/ OGO IDENTIFICATION CHECK DIGIT BANK ACCOUNT NUMBER AMOUNT INDIVIDUAL IDENTIFICATION NUMBER/ IDENTIFICATION NUMBER INDIVIDUAL NAME/ RECEIVING COMPANY NAME DISCRETIONARY DATA ADDENDA RECORD INDICATOR TRACE NUMBER Field Inclusion Requirement M R M O R R M M Contents ‘6’ Numeric 1 TTTTAAAA Numeric Alphanumeric $$$$$$$$¢¢ Alphanumeric ‘1’ 3 Numeric Length 1 2 8 1 17 12 15 22 2 1 15 NOTE: For Refused NOC Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.

Changed to the Routing Number of the institution receiving the Refused NOC Entry (i.e., the
OB of the NOC Entry).
Changed to the Check Digit calculated according to BEFTN standards and based on the
Routing Number.
Changed to the Trace Number assigned by the institution preparing the Refused NOC Entry
(i.e., the RB of the NOC Entry).
6.6.8 Addenda Record Format for Automated Refused Notifications of Change

Refused Notification of Change ‐ Addenda Record FIELD 1 2 3 4 5 6 7 8 9 10 11 DATA ELEMENT NAME RECORD TYPE CODE ADDENDA TYPE CODE REFUSED COR CODE ORIGINAL ENTRY TRACE NUMBER RESERVED ORIGINAL RB IDENTIFICATION CORRECTED DATA CHANGE CODE COR TRACE SEQUENCE NUMBER RESERVED TRACE NUMBER Field Inclusion Requirement M N/A R M N/A M Contents ‘7’ ‘98’ Alphanumeric 1 Numeric Blank TTTTAAAA Alphanumeric 2 Alphanumeric Numeric Blank Numeric Length 1 2 3 15 6 8 29 3 7 5 15 NOTE: This record format should only be used in the refusal of a Notification of Change Entry. The File, Batch, and Entry Detail record formats of an Automated Refused Notification of Change are the same as an Automated Notification of Change with the exception of the Addenda Record.

Copy data from positions 07‐21 of the Addenda Record of the original Notification of
Change.
Copy data from positions 04‐06 of the Addenda Record of the original Notification of
Change.

APPENDIX SEVEN
BEFTN PARTICIPANT AGREEMENT
(On Tk. 150 Non-Judicial Stamp)
BANGLADESH ELECTRONIC FUNDS TRANSFER NETWORK
PARTICIPANT AGREEMENT AND INDEMNITY
In consideration of the undersigned being admitted as a participating banking company of the Bangladesh Electronic Funds Transfer Network ("BEFTN") acting as a facility to operate an automated clearing house of the Bangladesh Bank providing settlement and other services, and of the mutual indemnification of the undersigned by each other participating banking company of BEFTN: the undersigned, which intends to act as a participating banking company of BEFTN, hereby agrees with the Bangladesh Bank, and with each other participating banking company:

to comply with and be subject to the BEFTN Operating Rules, (collectively referred to as the
"BEFTN Rules") including descriptive requirements, as in effect from time to time;
to make all payments required by the BEFTN Rules;
to indemnify and hold harmless the Bangladesh Bank and each other participating banking
company from any and all costs, charges, claims, demands, expenses (including costs of investigation and attorneys' fees and expenses of litigation), losses, liabilities, damages, judgments, fines, penalties, interest, and amounts paid in settlement (each referred to herein as a "cost") arising from any failure on the part of the undersigned to exercise ordinary care or to comply with any of the provisions of the BEFTN Rules, except for amounts paid in settlement of such costs unless the undersigned shall have received 10 days' prior written notice of the proposed settlement thereof; This agreement shall be governed by and construed in accordance with the laws the People’s Republic of Bangladesh. The undersigned and the Bangladesh Bank submit to the exclusive jurisdiction of the courts of the People’s Republic of Bangladesh. This agreement shall inure to the benefit of the Bangladesh Bank and shall be binding on the undersigned and its successors and assigns, except no Participating Banking Company may transfer or assign its rights or obligations hereunder except as expressly provided in the BEFTN Rules. Date:
(Participating Banking Company)
By :
(Signature)
Print Name :
Title :
Accepted this ________ day of _______, _______ Bangladesh Bank By : _______________________________ Print Name : _______________________________ Title : _______________________________

APPENDIX EIGHT
SAMPLE BEFTN ORIGINATION AGREEMENT
BEFTN ORIGINATION AGREEMENT
THIS AGREEMENT is entered into effective as of the __ day of _____________, 20, by and between ______________________, (the “Originator”), and _____________________ (“Bank”). RECITALS WHEREAS, the Originator has requested that Bank permit it to initiate electronic credit and debit entries (and “Entry” or “Entries”) for payment to accounts maintained at Bank and other Banks, by means of the Bangladesh Electronic Funds Transfer Network (the “BEFTN”); and WHEREAS, Bank is willing to provide such services to Originator in accordance with the terms and conditions contained herein. NOW THEREFORE, in consideration of the mutual promises contained herein, the sufficiency of which is hereby acknowledged, it is agreed as follows:
AGREEMENT

Transmission of Entries.
1.1.Bank, in its capacity as an originating deposit Bank, will transmit the Entries initiated by the Originator into the BEFTN and with those procedures provided for herein and as provided in the BEFTN Rules; as such rules may be amended from time to time. 1.2.The Originator will utilize Bank’s origination system using BEFTN format or such other format or medium as the parties may mutually agree upon for the transmittal of Entries to Bank. 1.3.All Entries will be transmitted to Bank in accordance with the processing schedule set forth on Attachment A (Processing Schedule). 1.4.The total amount of Entries sent by the Originator shall not exceed the established limits set forth on Attachment B (Exposure Limit).
Compliance with Law, BEFTN Rules.
2.1. The Originator will comply with all BEFTN Rules, and applicable regulations and laws (“Rules
and Laws”) with respect to the subject matter of this agreement. The specific duties of the Originator provided in this agreement shall in no way limit the foregoing undertaking. :: WARNING ::
BEFTN Origination Agreement Must Be Customized For BEFTN Originator and Application

2.2. It will be the sole responsibility of the Originator to ensure that the transmission of Entries
and origination of BEFTN transactions are in full compliance with all Rules and Laws.
2.3. The Originator will obtain written authorizations for consumer entries in accordance with
the BEFTN Rules and Laws, and shall retain the original or a reasonable copy thereof for no less than two (2) years following the termination or revocation of such authorization.
3. Rejection of Entries.
3.1. In the event that any Entries are rejected by the BEFTN System for any reason, it shall be the
responsibility of the Originator to remake such entries. Bank shall have no responsibility to reinitiate any returned entries until Originator remakes such entries in accordance with the BEFTN Rules.
3.2. Bank shall have the right to reject any Entry that does not fully comply with the
requirements of this agreement, which determination shall be made in Bank’s sole discretion. In addition, Bank shall have the right to reject any Entry that is made while the Originator is in default of any requirements of this agreement, including but not limited to the requirement to maintain an adequate account balance or line of credit.
4. Return of Entries. Bank will notify the Originator of the receipt of any returned entry or
notification of change entry no later than one business day after the business day of such receipt. The Originator may reinitiate any returned entry at their discretion, provided the reinitiating is in accordance with applicable sections of the BEFTN Rules. Bank will not reinitiate any returned entries automatically.
5. Originator Error.
5.1. If the Originator discovers that any Entry it has initiated was made in error, it must notify
Bank of the error within 24 hours. In such a case, Bank will utilize its best efforts to initiate an adjusting entry or stop processing of any “on‐us” Entry. Should Bank be unable to stop the Entry from posting, or if it is too late to withdraw the item from the BEFTN System, the Originator may initiate a reversal file to correct the Entry, as provided for and abiding by the BEFTN Rules.
5.2. Should a reversal be created for an individual Entry or Entries, the receiver(s) of the Entries
must be notified by the Originator of the reversal no later than the settlement date of the reversing Entry.
5.3. Should a reversal be created for a complete file reversal, the Originator must advise Bank
within five (5) business days of settlement.
6. Settlement. The Originator and Bank shall comply with the settlement procedures described in
Attachment C (Settlement).
7. Account Reconciliation. Entries transmitted by Bank will be reflected on Originator’s periodic
statement. Originator agrees to notify Bank immediately of any discrepancy between Originator’s records and the information shown on any such periodic statement. If Originator fails to notify Bank of any discrepancy within sixty (60) days of receipt of the corresponding periodic statement, Originator agrees that Bank will not be liable for any losses resulting from Originator’s failure to give such notice.
8. Security Procedures. The Originator and Bank shall comply with the security procedures
described in Attachment D (Security Procedures). The Originator acknowledges that the purpose of the security procedures is for verification of file authenticity and not to detect errors within

the transmitted file or individual transactions. No security procedure for detection of any such error has been agreed upon between the Originator and Bank.
9. Payment for Services. The Originator agrees to compensate Bank for providing the services
referred to herein at the prices set forth in Attachment E. The prices contained therein do not include, and Originator shall be responsible for payment of, any sales, use, excise, value added, utility or other taxes relating to the services provided for herein. Bank may amend the Pricing
Schedule at any time upon delivery of notice thereof to Originator.
10. Limitation of Liability.
10.1. BANK’S LIABILITY HEREUNDER SHALL BE LIMITED TO LIABILITY FOR ITS OWN GROSS
NEGLIGENCE OR WILLFUL MISCONDUCT. NOTWITHSTANDING THE FOREGOING, IN NO EVENT SHALL BANK BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OR FOR ANY LOST OR IMPUTED PROFITS OR REVENUES OR COSTS OF COVER ARISING FROM OR RELATED TO THE SERVICES PROVIDED UNDER THIS AGREEMENT, REGARDLESS OF THE LEGAL THEORY UNDER WHICH SUCH LIABILITY IS ASSERTED AND REGARDLESS OF WHETHER A PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH LIABILITY, LOSS OR DAMAGE. ORIGINATOR’S EXCLUSIVE REMEDIES FOR ANY AND ALL CLAIMS RELATED TO THE SERVICES PROVIDED HEREUNDER SHALL BE LIMITED TO THE AMOUNT RECOVERABLE BY BANK FROM THE BEFTNSYSTEM OPERATOR, OR ANY OTHER SUB MEMBER PURSUANT TO THE BEFTN RULES OR ANY APPLICABLE INDEMNITY AGREEMENT.
10.2. Bank will not be liable for any failure or delay in transmission of an Entry if such
transmission would (1) result in Bank’s having exceeded any limitation upon its intra‐day net funds position established pursuant to Federal Reserve Guidelines, (2) violate any risk control provision promulgated by the Federal Reserve, or (3) violate any rule or regulation of any Bangladesh governmental regulatory authority.
11. Disclaimer of Warranties. ORIGINATOR ASSUMES TOTAL RESPONSIBILITY FOR USE OF THE
SERVICES PROVIDED HEREUNDER. EXCEPT AS SPECIFICALLY SET FORTH HEREIN, THE SERVICES AND ANY RELATED SOFTWARE, IF ANY, ARE PROVIDED WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Indemnification of Bank.
12.1. The Originator will indemnify Bank if Bank incurs any financial loss or liability (including
attorneys’ fees and associated expenses) due to the breach, with respect to any Entries initiated by the Originator, of any of the warranties of an Originating Bank contained in the BEFTN Rules, except those due to the gross negligence of Bank. This includes reimbursement by the Originator to Bank of any fines imposed on Bank due to breaches of the BEFTN Rules by the Originator.
12.2. The Originator will indemnify Bank against any loss, liability or expense (including
attorneys’ fees and associated expenses) resulting from any claim that Bank is responsible for any act or omission of the Originator or any other person or entity associated with or affected by the services to be performed hereunder, including but not limited to any receiver, receiving Bank, or any federal reserve financial institution.

Notices. Except as otherwise provided herein, all required notices shall be in writing,
transmitted to the parties’ addresses specified below or such other addresses as may be specified by written notice, and will be considered given either: (i) when delivered in person to the recipient specified below; (ii) when deposited in either registered or certified Mail, return receipt requested, postage prepaid; or (iii) when delivered to an overnight courier service. If to Bank:

Attn: _________________________
If to Originator:

Attn: _________________________
Bank shall be entitled to rely on any written notice or other written communication believed by it in good faith to be genuine and to have been signed by an authorized representative of Originator, and any such communication shall be deemed to have been signed by such person. The names and signatures of authorized representatives of Originator are set forth in Attachment F (Authorized Representatives). Originator may add or delete any authorized representative by written notice to Bank signed by an authorized representative other than that being added or deleted. Such notice shall be effective on the second business day following the day of Bank’s receipt thereof.
14. Originator Data Retention. Originator will retain data on file adequate to permit remaking of
Entries for ten (10) days following the date of their transmittal by Bank as provided herein, and shall provide copies of such data to Bank upon its request.
15. Assignment. Originator may not assign this agreement or any of its rights or obligations
hereunder without the prior written consent of Bank. This agreement shall be binding upon and inure to the benefit of the parties hereto and their respective legal representatives, successors and assigns.
16. No Third Party Beneficiaries. The terms, representations, warranties and agreements of the
parties set forth in this Agreement are not intended for, nor shall they be for the benefit of or enforceable by, any person or entity that is not a party to this agreement.
17. Severability. If any provision of this agreement is held to be unenforceable, the unenforceable
provision shall be construed as nearly as possible to reflect the original intent of the parties and the remaining provisions shall remain in full force and effect.
18. Force Majeure. Bank will not be liable for any delay or failure to perform its obligations
hereunder if such delay or failure is caused by a Force Majeure Event. For purposes hereof, a “Force Majeure Event” means an unforeseeable event beyond the reasonable control of Bank, including but not limited to: an act of God; fire; flood; labour strike; sabotage; fiber or data‐line cut; lack of or delay in transportation; government codes, ordinances, laws, rules, regulations or restrictions; war or civil disorder.
19. Waiver. Bank’s failure to insist upon strict performance of any provision of this agreement shall
not be construed as a waiver of any of its rights hereunder.
20. Termination. The Originator may terminate this agreement at any time upon delivery of thirty
(30) days written notice of its intent to so terminate. Bank may terminate this agreement immediately upon delivering written notice thereof to the Originator. Any termination of this

agreement shall not affect any of the Originator’s obligations arising pursuant to the terms of this agreement prior to such termination.
21. Controlling Documents; Governing Law. In the event of a conflict between the terms of any
attachment to this agreement and the terms of this agreement, the terms of the attachment shall control. This agreement shall be governed by the laws of the People’s Republic of Bangladesh.
22. Entire Agreement. This agreement, together with any attachments hereto, constitute one and
the same legally binding instrument and the entire agreement between the Originator and Bank with respect to the subject matter hereof, and supersedes all prior offers, contracts, agreements, representations and understandings made to or with the Originator, whether oral or written, relating to the subject matter hereof. All amendments to this agreement shall be in writing and signed by authorized representatives of the parties. IN WITNESS WHEREOF, the undersigned have duly executed the Agreement by their duly authorized officers. BANK By : _______________________ Print Name : _______________________ Title : _______________________ ORIGINATOR By : _______________________ Print Name : _______________________ Title : _______________________

ATTACHMENT A
Processing Schedule
The following schedule is for the use of the Originator to determine deadlines for sending origination files to Bank. Files received after these deadlines may not be guaranteed delivery to the BEFTN Operator for next‐day settlement.

Payroll Credits: All payroll credit origination will be sent to the Bank by 1:00 p.m. time two
business days before the settlement date of the subject Entries.
Debit Entry: The data file containing debit entry information will transmitted to Bank BEFTN
Department by 3:00 p.m. one business day before the settlement date of the subject Entries. All files received after the above‐referenced 3:00 p.m. deadline will be processed the following business day.
Other Credits: All other credit origination Entries must be submitted by 6:00 p.m. business day
before the settlement date of the subject Entries.
Note to Originator
Credit items sent earlier than two days before intended settlement date will be warehoused with Bank until two days before the intended settlement date. Debit items sent earlier than one day before the intended settlement date will be warehoused with Bank until one day before the intended settlement date. If you intend to warehouse items with Bank, advance notification of your intentions is required.

:: Warning ::

ATTACHMENT B
Exposure Limit
The total daily limit of all originated debit and credit Entries combined will be set equal to the average daily balance in the Originator’s Bank cash management account during the preceding calendar quarter, and will be adjusted on a quarterly basis. The current limit is TK 5 lakh per day. The Originator’s daily limit for originated credit Entries will be the lesser of the Originator’s current balance in the Originator’s Bank cash management account or Tk1 lakh. The daily limit for originated debit Entries to consumer accounts will be equal to the available balance in the Originator’s line‐of‐credit loan with Bank. The Originator will be required to maintain an available loan balance of at least Tk1 lakh at all times. :: Warning ::

ATTACHMENT C
Settlement
The Originator will provide immediately available funds to offset any credit entries originated by it not later than the corresponding settlement date. The Originator will receive immediately available funds for any electronic debit entries initiated by it not later than the settlement date of the items. Provisions may be made for holding accounts to be maintained for posting of any return debit items received, as stated in this agreement and abiding by the BEFTN Rules. The Originator will promptly provide immediately available funds to indemnify Bank if any debit items are rejected after Bank has permitted the Originator to withdraw immediately available funds, should funds not be available in the Originator’s accounts to cover the amount of the rejected items. In order to provide available funds to cover the amount of rejected items, Originator will be required to maintain an available line‐of‐credit loan with Bank in an amount of at least 5% of the previous month’s total debit entry originations.

:: Warning ::

ATTACHMENT D
Security Procedures
The Originator is required to utilize the Bank’s security procedures for all origination activity. Dual approval of all template and payment initiation functions will be required. The single entry maximum transaction Taka limit will be set at TK ______ for BEFTN user. All originated files in excess of TK _________ sent to Bank will require a telephone verification by Bank with an Originator Authorized Representative (see Attachment F) before the files will be released. All origination files sent to Bank will require a second verification of file entry and Taka totals by an Originator Authorized Representative. This second verification can be submitted by electronic mail or facsimile with signature to Bank’s BEFTN Department. The Originator is responsible to strictly establish and to maintain procedures to safeguard against unauthorized transactions. The Originator warrants that no individual will be allowed to initiate transfers in the absence of proper supervision and safeguards, and agrees to take reasonable steps to maintain the confidentiality of the security procedures and any passwords, codes, security devices, and related instructions provided by Bank. If the Originator believes or suspects that any such information has been accessed by an unauthorized individual, the Originator will verbally notify Bank immediately, followed by written confirmation. The occurrence of such notification will not affect any transfers made in good faith by Bank prior to the notification and within a reasonable time period to prevent unauthorized transfers. :: Warning ::

ATTACHMENT E
Authorized Representatives
All BEFTN transaction files/listings must be delivered with a transmittal document with authorized signature(s). Date : ________________________ Originator Name : ________________________ Company ID Number : ________________________ The ______ signatures below are the signatures of employees vested by our Board of Directors, who have full authority to sign transmittal registers to be used in conjunction with the submission of BEFTN files. The number of signatures that are required to submit a file for processing: ______ Name Phone # Signature

Authorized Signature : ________________________ Title : ________________________ Date : ________________________ :: Warning ::

DCMPS Circular No. 9: Bangladesh Electronic Fund Transfer Network (BEFTN) Operating Rules

Lineage: Superseded

Timeline