BangladeshElectronicFundsTransferNetwork

(BEFTN)

OPERATINGRULES

PaymentSystemsDivision
DepartmentofCurrencyManagementandPaymentSystems
BangladeshBank

10August2010

FOREWORD

Amodernnationalpaymentsystemisthebackboneforacountrysmonetaryandfinancialinfrastructureand
anadvancedpaymentsystemplaysacriticalroleinthecountryscurrentandfutureeconomicdevelopment.
Several years ago, Bangladesh Bank in partnership with the U.K. Department for International Development
(DFID) embarked on a project to modernize Bangladeshs national payments system. The project is
multifacetedanditsprimaryobjectivewastoincreaseandimprovethedeliveryofworkersremittances.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 interbank 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
developmentofamodernpaymentssysteminfrastructure.BEFTNwillbethemostpowerfulpaymentssystem
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
everybankedandnonbankedconsumeraswellaseverybusinesscustomertofacilitateelectroniccommerce.
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,veteranspayments,governmentlicencesandpersontopersonpaymentsaswellasdebittransfer
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
futureBEFTNwillbelinkedtothemobilepaymentinitiativescurrentlybeingdevelopedwithinBangladesh,the
mobilenetworkswillprovidethegatewayforthenonbankedtoreachbankedconsumersandbusinessesand
forbankedconsumersandbusinessestoreachthenonbanked.

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
executeacontractualagreementthatwillbindthebanktocomplyandadheretotheBEFTNRulescompleting
thelegalunderpinningofthesystem.

IwouldliketotakethisopportunitytothankDFID,theRPPAdvisoryTeam,andespeciallyGeorgeThomas,the
RPP Regulatory Advisor for their contributions in the development of the BEFTN Rules. I would also like to
thanktheNationalAutomatedClearingHouseAssociation(NACHA)oftheUnitedStatesforallowingtheirACH
rulestobeusedasthefoundationfortheBEFTNRules.

Dasgupta Asim Kumar

Executive Director & Project Director,
Bangladesh Bank, RPP Project
10 August 2010

TABLEOFCONTENTS

INTRODUCTION ............................................................................................................................... 1
BEFTNOVERVIEW ................................................................................................................................................... 1
1.
ABOUTBEFTN .............................................................................................................................................. 1
2.
PARTICIPANTSINBEFTN ............................................................................................................................ 1
3.
EFTTRANSACTIONFLOW............................................................................................................................. 2
4.
CONSUMERVS.CORPORATEPAYMENTS .................................................................................................... 5
5.
PAYMENTAPPLICATIONS............................................................................................................................. 5
6.
SETTLEMENTANDPOSTING......................................................................................................................... 6
7.
LEGALFRAMEWORK .................................................................................................................................... 7

ARTICLEONE..................................................................................................................................... 9
GENERAL................................................................................................................................................................. 9
SECTION1.1ApplicationofRules ........................................................................................................................... 9
SECTION1.2CompliancewithRules....................................................................................................................... 9
1.2.1Compensation................................................................................................................................................ 9
1.2.2DisputeResolution........................................................................................................................................ 9
SECTION1.3ExcusedDelay .................................................................................................................................... 9
SECTION1.4DaysonWhichInstitutionorFacilityisClosed .................................................................................. 9
SECTION1.5Records .............................................................................................................................................. 9
1.5.1RecordsofEntries.......................................................................................................................................... 9
1.5.2RecordRetention........................................................................................................................................... 9
1.5.3ElectronicRecordsPermitted ...................................................................................................................... 10
SECTION1.6ChoiceofLaw................................................................................................................................... 10

ARTICLETWO .................................................................................................................................11
ORIGINATIONOFENTRIES .................................................................................................................................... 11
SECTION2.1PrerequisitestoOrigination............................................................................................................. 11
2.1.1OriginatorAuthorizationandAgreement.................................................................................................... 11
2.1.2ReceiverAuthorizationandAgreement ...................................................................................................... 11
2.1.3ExceptiontoAuthorizationRequirement.................................................................................................... 11
2.1.4NoticebyOB ................................................................................................................................................ 11
2.1.5NoticebyRB ................................................................................................................................................ 12
2.1.6OBExposureLimits ...................................................................................................................................... 12
SECTION2.2WarrantiesandLiabilitiesofOriginatingBanks............................................................................... 12
2.2.1Warranties ................................................................................................................................................... 12
2.2.1.1AuthorizationbyOriginatorandReceiver ................................................................................................ 12
2.2.1.2TimelinessofEntries................................................................................................................................. 12
2.2.1.3ComplianceWithOtherRequirements .................................................................................................... 12
2.2.1.4RevocationofAuthorization..................................................................................................................... 13
2.2.1.5TerminationofAuthorizationbyOperationofLaw ................................................................................. 13
2.2.1.6TransmittalofRequiredInformation........................................................................................................ 13
2.2.1.7ReclamationEntries.................................................................................................................................. 13
2.2.1.8CorrespondentBank................................................................................................................................. 13
2.2.2Limitation..................................................................................................................................................... 13
2.2.3LiabilityforBreachofWarranty................................................................................................................... 14
SECTION2.3ReversingFiles ................................................................................................................................. 14
2.3.1GeneralRule ................................................................................................................................................ 14
2.3.2LimitationsonInitiationofReversingFiles.................................................................................................. 14
2.3.3NotificationbyBEFTNAuthority.................................................................................................................. 14
2.3.4CorrectingFiles ............................................................................................................................................ 14
2.3.5Indemnification............................................................................................................................................ 14
2.3.6InapplicableProvisions ................................................................................................................................ 15
SECTION2.4ReversingEntries ............................................................................................................................. 15
2.4.1GeneralRule ................................................................................................................................................ 15

2.4.2Indemnification............................................................................................................................................ 15
2.4.3InapplicableProvisions ................................................................................................................................ 15
SECTION2.5ReclamationEntries ......................................................................................................................... 15
2.5.1GeneralRule ................................................................................................................................................ 15
2.5.2Definition ..................................................................................................................................................... 16
2.5.3InapplicableProvisions ................................................................................................................................ 16
SECTION2.6ReinitiatingReturnedEntriesbyOriginators ................................................................................... 16
SECTION2.7MediaandFormatSpecificationRequirements .............................................................................. 16
SECTION2.8ReleaseofInformation .................................................................................................................... 16

ARTICLETHREE .............................................................................................................................17
OBLIGATIONSOFORIGINATORS........................................................................................................................... 17
SECTION3.1General ............................................................................................................................................ 17
SECTION3.2ConsumerAccountsNoticebyOriginatortoReceiverofVariableDebits .................................... 17
3.2.1NoticeofChangeinAmount ....................................................................................................................... 17
3.2.2ReceiversElection....................................................................................................................................... 17
3.2.3NoticeofChangeinScheduledDebitingDate............................................................................................. 17
SECTION3.3RecordofAuthorization................................................................................................................... 17

ARTICLEFOUR................................................................................................................................18
RECEIPTOFENTRIES ............................................................................................................................................. 18
SECTION4.1GeneralRightsandObligationsofRB .............................................................................................. 18
4.1.1RighttoInformationRegardingEntries ....................................................................................................... 18
4.1.2ObligationtoAcceptEntries ........................................................................................................................ 18
4.1.3RelianceonAccountNumbersforPostingofEntries.................................................................................. 18
SECTION4.2WarrantiesofReceivingBanks ........................................................................................................ 18
SECTION4.3AvailabilityofEntries,CreditingandDebitingofEntries ................................................................. 18
4.3.1AvailabilityofCreditEntriestoReceivers.................................................................................................... 18
4.3.2TimeofDebitingofEntries .......................................................................................................................... 19
4.3.3ProvisionofPaymentRelatedInformationtoReceiver .............................................................................. 19
4.3.4CreditingofOriginatorsAccountsbyReceiver ........................................................................................... 19
4.3.5RightsofReceiverUponUnauthorizedDebittoItsAccount....................................................................... 19
4.3.6RelianceonStandardEntryClassCodes...................................................................................................... 19
4.3.7ReimbursementofRB.................................................................................................................................. 19
SECTION4.4PeriodicStatements......................................................................................................................... 19
SECTION4.5NoticetoReceiver............................................................................................................................ 20
SECTION4.6ReleaseofInformation .................................................................................................................... 20
SECTION4.7LiabilityofRBforBenefitPayments ................................................................................................ 20
4.7.1LiabilityofRB ............................................................................................................................................... 20
4.7.2AmountofRBLiability ................................................................................................................................. 20
4.7.3DemandforPayment................................................................................................................................... 20
4.7.4Timing .......................................................................................................................................................... 20
4.7.5AlterationbyAgreement ............................................................................................................................. 20

ARTICLEFIVE..................................................................................................................................22
RETURN,ADJUSTMENT,CORRECTION,ANDACKNOWLEDGMENT...................................................................... 22
OFENTRIESANDENTRYINFORMATION............................................................................................................... 22
SECTION5.1ReturnofEntries.............................................................................................................................. 22
5.1.1RighttoReturnEntries ................................................................................................................................ 22
5.1.2RequirementsofReturns............................................................................................................................. 22
5.1.3RestrictionsonRighttoReturn.................................................................................................................... 22
5.1.4CreditEntriesReturnedbyReceiver............................................................................................................ 22
5.1.5ReturnofUnpostedCreditEntries ............................................................................................................. 22
5.1.6AcceptanceofReturnEntriesbyOB............................................................................................................ 22
5.1.7ReinitiationofReturnEntriesbyOB........................................................................................................... 23
SECTION5.2DishonourofReturnEntries ............................................................................................................ 23

5.2.1DishonourofReturnbyOB.......................................................................................................................... 23
5.2.2ContestingofDishonouredReturnsbyRB .................................................................................................. 23
5.2.3ContestingaContestedDishonouredReturn.............................................................................................. 23
5.2.4CorrectedReturns........................................................................................................................................ 23
SECTION5.3NotificationofChange ..................................................................................................................... 23
5.3.1NotificationsofChange;RBWarrantiesandIndemnity.............................................................................. 23
5.3.2OBandOriginatorActiononNotificationofChange .................................................................................. 24
SECTION5.4RefusedNotificationofChange ....................................................................................................... 24
5.4.1OBRighttoRefuseNotificationofChangeEntries...................................................................................... 24
5.4.2RBActiononRefusedNotificationofChange ............................................................................................. 24

ARTICLESIX.....................................................................................................................................25
SETTLEMENTANDACCOUNTABILITY.................................................................................................................... 25
SECTION6.1MaintenanceofCentralBankAccount ............................................................................................ 25
SECTION6.2Settlement ....................................................................................................................................... 25
SECTION6.3EffectofSettlement......................................................................................................................... 25
SECTION6.4AccountabilityforEntries ................................................................................................................ 25
SECTION6.5EffectofRBClosingonTimeofSettlement ..................................................................................... 25
SECTION6.6EffectofOBClosingonTimeofSettlement .................................................................................... 25

ARTICLESEVEN ..............................................................................................................................26
RECALL,STOPPAYMENT,RECREDIT,ANDADJUSTMENT ..................................................................................... 26
SECTION7.1RecallbyOBorOriginator ............................................................................................................... 26
SECTION7.2OBRequestforReturn..................................................................................................................... 26
SECTION7.3OBAgreestoAcceptaCorporateDebitReturn............................................................................... 26
SECTION7.4StopPaymentAffectingConsumerAccounts .................................................................................. 26
SECTION7.5StopPaymentAffectingNonConsumerAccounts .......................................................................... 26
SECTION7.6ReceiversRighttoRecredit............................................................................................................. 27
7.6.1ReceiversRighttoRecredit......................................................................................................................... 27
7.6.2ReceiversWrittenStatement ..................................................................................................................... 27
7.6.3UnauthorizedDebitEntry............................................................................................................................ 27
7.6.4WaiverofRighttoRecredit ........................................................................................................................ 27
7.6.5EffectofExecutionofWaiver ...................................................................................................................... 27
7.6.6RecreditRightNotExclusive....................................................................................................................... 28
SECTION7.7AdjustmentEntries .......................................................................................................................... 28
7.7.1RBsRighttoAdjustment............................................................................................................................. 28
7.7.2WarrantyofRB ............................................................................................................................................ 28
7.7.3CopyofWrittenStatement ......................................................................................................................... 28
7.7.4AcceptanceofAdjustmentEntriesbyOB.................................................................................................... 28

ARTICLEEIGHT ..............................................................................................................................29
OBLIGATIONSOFTHEBEFTNAUTHORITY ............................................................................................................ 29
SECTION8.1ProcessingObligation ...................................................................................................................... 29
SECTION8.2ReturnandRejectionbyBEFTN ....................................................................................................... 29
SECTION8.3OriginatorStatusCodeReview ........................................................................................................ 29
SECTION8.4OptionalServices ............................................................................................................................. 29
SECTION8.5NonSettledEntries.......................................................................................................................... 29
SECTION8.6EntriesOriginatedtoaRBthatCannotSettle ................................................................................. 29
SECTION8.7EntriesReceivedfromanOBthatCannotSettle ............................................................................. 30
SECTION8.8RecordofEntries ............................................................................................................................. 30

ARTICLENINE .................................................................................................................................31
RESPONSIBILITIESOFBANGLADESHBANKANDBEFTNPARTICIPANTS ............................................................... 31
SECTION9.1General ............................................................................................................................................ 31
SECTION9.2SendingCreditandDebitItems ....................................................................................................... 31
SECTION9.3SecurityProcedures ......................................................................................................................... 31

SECTION9.4SendingBanksAgreements ............................................................................................................ 32
SECTION9.5ProcessingofItems.......................................................................................................................... 32
SECTION9.6DeliveryofItems.............................................................................................................................. 33
SECTION9.7TimeSchedules,SettlementDatesandExtensionofTimeLimits ................................................... 34
SECTION9.8DesignationofSettlementAccount................................................................................................. 34
SECTION9.9Settlement ....................................................................................................................................... 35
SECTION9.10AvailabilityofCredit....................................................................................................................... 36
SECTION9.11ReceivingBanksAgreements........................................................................................................ 36
SECTION9.12RevocationofItems ....................................................................................................................... 36
SECTION9.13ReturnofItemsandFunds ............................................................................................................ 37
SECTION9.14DisputedReturns ........................................................................................................................... 37
SECTION9.15AdvicesofCreditandDebit;ReportingofErrors........................................................................... 37
SECTION9.16Records .......................................................................................................................................... 37
SECTION9.17Fees................................................................................................................................................ 37
SECTION9.18NonValueMessages ..................................................................................................................... 37
SECTION9.19BangladeshBankLiability .............................................................................................................. 38
SECTION9.20AsofAdjustments.......................................................................................................................... 38
SECTION9.21RighttoAmend .............................................................................................................................. 38

ARTICLETEN...................................................................................................................................39
DEFINITIONOFTERMS.......................................................................................................................................... 39
SECTION10.1DefinitionsAsUsedInTheseRules................................................................................................ 39
SECTION10.2ConstructionRules......................................................................................................................... 41
SECTION10.3Otherdefinitions............................................................................................................................ 42

THEAPPENDICES...........................................................................................................................47
TECHNICALSPECIFICATIONS................................................................................................................................. 47
BEFTNPARTICIPATIONAGREEMENT .................................................................................................................... 47

APPENDIXONE ...............................................................................................................................48
BEFTNFILEEXCHANGESPECIFICATIONS .............................................................................................................. 48
SECTION1.1ElectronicTransmissionRequirements............................................................................................ 48
SECTION1.2BEFTNCD/DVDSpecifications.......................................................................................................... 48
SECTION1.3DataSpecifications........................................................................................................................... 48
SECTION1.4SequenceofRecordsinBEFTNFiles ................................................................................................ 48
SECTION1.5FileStructure.................................................................................................................................... 49
SECTION1.6TraceNumberSequenceinBEFTNFiles .......................................................................................... 50

APPENDIXTWO..............................................................................................................................51
BEFTNRECORDFORMATSPECIFICATIONS ........................................................................................................... 51
SECTION2.1BEFTNRecordFormats .................................................................................................................... 51
2.1.1BEFTNFileRecordFormatforAllEntries..................................................................................................... 51
2.1.2BEFTNBatchRecordFormatforAllEntries ................................................................................................. 52
2.1.3SequenceofRecordsforADVEntries.......................................................................................................... 52
2.1.3SequenceofRecordsforADVEntries(continued) ...................................................................................... 53
2.1.4SequenceofRecordsforCCDEntries .......................................................................................................... 53
2.1.5SequenceofRecordsforCIEEntries............................................................................................................ 54
2.1.6SequenceofRecordsforCTXEntries........................................................................................................... 54
2.1.7SequenceofRecordsforPPDEntries .......................................................................................................... 55
2.1.8SequenceofRecordsforTRXEntries........................................................................................................... 55
SECTION2.2CodeValues ..................................................................................................................................... 55
SECTION2.3GlossaryofFileFormatDataElements............................................................................................ 58

APPENDIXTHREE..........................................................................................................................59

SPECIFICATIONSFORDATAACCEPTANCE ............................................................................................................ 59
SECTION3.1FileAcknowledgment ...................................................................................................................... 59
SECTION3.2FileLevelRejectOption ................................................................................................................... 59
SECTION3.3BatchLevelRejectOption................................................................................................................ 60
SECTION3.4AutomaticFileRejections ................................................................................................................ 60
SECTION3.5AutomaticBatchRejection .............................................................................................................. 60
SECTION3.6AutomaticEntryDetailReturnEntry ............................................................................................... 61

APPENDIXFOUR ............................................................................................................................62
MINIMUMDESCRIPTIONSTANDARDS ................................................................................................................. 62

APPENDIXFIVE ..............................................................................................................................63
RETURNENTRIES .................................................................................................................................................. 63
SECTION5.1AutomatedReturnEntries............................................................................................................... 63
SECTION5.2NonAutomatedReturnEntries ....................................................................................................... 63
SECTION5.3AdjustmentEntries .......................................................................................................................... 63
SECTION5.4TableofReturnReasonCodes......................................................................................................... 64
SECTION5.5RecordFormatsforAutomatedandConvertedReturnEntries ...................................................... 68
5.5.1CorporateEntryDetailRecordFormatforReturns ..................................................................................... 68
5.5.2EntryDetailRecordFormatforReturns ...................................................................................................... 69
5.5.4AddendaRecordFormatforReturns........................................................................................................... 69
SECTION5.6DishonouredReturnEntriesbyBEFTN ............................................................................................ 70
5.6.1Company/BatchHeaderRecordFormatforAutomatedDishonouredReturns.......................................... 70
5.6.2CorporateEntryDetailRecordforAutomatedDishonouredReturns......................................................... 71
5.6.3EntryDetailRecordFormatforAutomatedDishonouredReturns ............................................................. 71
5.6.5AddendaRecordFormatforAutomatedDishonouredReturns.................................................................. 72
SECTION5.7ContestedDishonouredBEFTNReturnEntries................................................................................ 72
5.7.1AutomatedContestedDishonouredReturnEntries.................................................................................... 72
5.7.2NonAutomatedContestedDishonouredReturnEntries............................................................................ 73
5.7.3CorrectedReturnEntries ............................................................................................................................. 73
5.7.4Company/BatchHeaderRecordFormatforAutomatedContestedDishonouredReturns ........................ 73
5.7.5CorporateEntryDetailRecordFormatforAutomatedContestedDishonouredReturns........................... 74
5.7.6EntryDetailRecordFormatforAutomatedContestedDishonouredReturns ............................................ 74
5.7.7AddendaRecordFormatforAutomatedContestedDishonouredReturns ................................................ 75

APPENDIXSIX .................................................................................................................................76
NOTIFICATIONOFCHANGE .................................................................................................................................. 76
SECTION6.1AutomatedNotificationofChange.................................................................................................. 76
SECTION6.2NonAutomatedNotificationofChange.......................................................................................... 76
SECTION6.3RefusedBEFTNNotificationofChange............................................................................................ 76
SECTION6.4MinimumDescriptionStandardsforNotificationsofChangeandCorrectedNotificationsof
Change.................................................................................................................................................................. 76
SECTION6.5TableofChangeCodes .................................................................................................................... 77
SECTION6.6RecordFormatsforAutomatedandConvertedNotificationsofChange........................................ 79
6.6.1Company/BatchHeaderRecordFormatforNotificationsofChange ......................................................... 79
6.6.2CorporateEntryDetailRecordFormatforNotificationsofChange............................................................ 79
6.6.3EntryDetailRecordFormatforNotificationsofChange ............................................................................. 80
6.6.4AddendaRecordFormatforNotificationsofChange ................................................................................. 80
6.6.5Company/BatchHeaderRecordFormatforAutomatedRefusedNotificationsofChange ........................ 81
6.6.6CorporateEntryDetailRecordFormatforAutomatedRefusedNotificationsofChange........................... 81
6.6.7EntryDetailRecordFormatforAutomatedRefusedNotificationsofChange ............................................ 82
6.6.8AddendaRecordFormatforAutomatedRefusedNotificationsofChange ................................................ 82

APPENDIXSEVEN...........................................................................................................................83

BEFTNPARTICIPANTAGREEMENT........................................................................................................................ 83

APPENDIXEIGHT...........................................................................................................................84
SAMPLEBEFTNORIGINATIONAGREEMENT......................................................................................................... 84

INTRODUCTION
BEFTNOVERVIEW
1. ABOUTBEFTN
TheBangladeshElectronicFundsTransferNetwork(BEFTN)willoperateasaprocessinganddelivery
centre providing for the distribution and settlement of electronic credit and debit instruments
among all participating banks. This Network will operate in a realtime batch processing mode.
Transactionfilesreceived fromthebanksduringthedaywillbeprocessedastheyarereceivedto
ensurethatifthereareconditionsthatwouldresultinafileorbatchreject thebanking company
will have sufficient time to fix the errors and resubmit the file. All payment transactions will be
calculatedintoasinglemultilateralnettingfigureforeachindividualbank.Finalsettlementwilltake
placeusingaccountsthataremaintainedwithBangladeshBank.
Participating banks in the EFT Network and the EFT Operator (BEFTN) will be interconnected via
communicationlinks.Theuseofacommunicationnetworkfacilitatesthetransmissionofpayments
informationthatprovidesfaster,saferandamoreefficientmeansofinterbankclearingthanwould
bepossibleusingtheexistingpaperbasedsystem.BEFTNwillprovidethecapabilitytoofferawide
range of electronic products that will improve payment services for the participating banks
customers.BEFTNwilldramaticallylowertheoperationalcost,reduceriskandwillalsoincreasethe
efficiencyoftheoverallpaymentprocess.
2. PARTICIPANTSINBEFTN
TheEFTNetworkisamultilateralelectronicclearingsysteminwhichelectronicpaymentinstructions
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
participantsinvolvedare:
(a) Originator.
(b) OriginatingBank(OB)
(c) BangladeshElectronicFundsTransferNetwork(EFTOperator)
(d) ReceivingBank(RB)
(e) Receiver
(f)
CorrespondentBank

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 consumers or a companys account. The
originatorexecutesanEFTfundtransferentrythroughanOriginatingBank(OB).
b)OriginatingBank(OB)
Theoriginatingbankisthebankwhichreceivespaymentinstructionsfromitsclient(theoriginator)
andforwardstheentrytotheBEFTN.AbankmayparticipateintheEFTsystemasareceivingbank
withoutactingasanoriginating bank; however,ifaBankchoosestooriginateEFTentries, itmust
alsoagreetoactasareceivingbank.
c)BangladeshElectronicFundsTransferNetwork(BEFTN)
BEFTNisthecentralclearingfacility,operatedbyBangladeshBankthatreceivesentriesfromOBs,
distributes the entries to appropriate RBs, and facilitates the settlement functions for the
participatingbankinginstitutions

d)ReceivingBank(RB)
ThereceivingbankisthebankthatwillreceiveEFTentriesfromBEFTNandposttheentriestothe
accountofitsdepositors(Receivers).
e)Receiver
Areceiverisaperson/organizationwhohasauthorizedanOriginatortotransmitanEFTentrytothe
accountofthereceivermaintainedwiththeReceivingBank(RB).
f)CorrespondentBank
InsomecasesanOriginator,OriginatingBankorReceivingBankmaychoosetousetheservicesofa
CorrespondentBankforallorpartoftheprocessofhandlingEFTentries.ACorrespondentBanks
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
BangladeshBankbeforeabankentersintoanagreementwiththeCorrespondentBank.

OriginatingBank

BEFTN

ReceivingBank

BangladeshBank
(Reporting&Settlement)

Authorization

Receiver
Originator
Figure1:ParticipantsinvolvedinanEFTtransaction
Authorization
Awrittenarrangementwiththeoriginatingcompanysignedby anemployeeorcustomertoallow
payments processed through the EFT Network to be deposited in or withdrawn from his or her
accountatabank.Authorizationcanalsobeawrittenagreementthatdefinestheterms,conditions
andlegalrelationshipbetweenOriginatorandReceiver.
3. EFTTRANSACTIONFLOW
InEFTterminology,OriginatorandReceiverrefertotheparticipantsthatinitiateandreceivetheEFT
entriesratherthanthefunds.Unlikeacheck,whichisalwaysadebitinstrument,anEFTentrymay
either be a credit or a debit entry. By examining what happens to the receivers account, one can
distinguish between an EFT Credit and EFT Debit transaction. If the receivers account is debited,
thentheentryisanEFTdebit.Ifthereceiversaccountiscredited,thentheentryisanEFTcredit.
Conversely,theoffsetofanEFTdebitisacredittotheoriginatorsaccountandtheoffsettoanEFT
creditisadebittotheOriginatorsaccount.
Inthelatersectionsthedescriptionofthetransactionand/orinstrumentstobeusedintheBEFTN
hasbeendescribedinlogicalsequenceregardlessoftheirimplementationschedule.


a)EFTCredits
EFT credit entries occur when an Originator initiates a transfer to move funds into a Receivers
account. For example,whena corporateuses thepayrollserviceata banktopaythesalaryofits
employeeeachmonth,thecorporateoriginatesthepaymentthroughtheOBtotransferthemoney
intotheaccountoftheemployee;theindividualisthereceiverinthisexample.
EFT credit transactions involve both consumer and corporate payments with separate rules and
regulationsforeach.ThemosttypicalconsumerEFTapplicationisDirectDepositofPayroll.

OriginatingBank

ReceivingBank

BEFTN

TK

TK

TK

Debit

Credit
Receiver

Originator

Figure2:EFTCreditTransactionsFlow

In the illustration above an EFT credit transaction flow for payroll payment is shown, where an
organizationinitiatesanEFTentrytocredititsemployeesaccount.
Someothercommoncreditapplicationsare:

InwardForeignremittances
Domesticremittances
Payrollprivateandgovernment
Dividends/Interest/RefundsofIPO
Businesstobusinesspayments(B2B)
Governmenttaxpayments
Governmentvendorpayments
Customerinitiatedtransactions

b)EFTDebits
In an EFT debit transaction, funds flow in the opposite direction to the information. Funds are
collectedfromtheReceiversaccountandtransferredtoanOriginatorsaccount,eventhoughthe
originatorinitiatestheentry.


IntheillustrationbelowitisshownthatautilitycompanyinitiatesanEFTentrytocollectitsbillfrom
theconsumer.
SomeexamplesofEFTdebitapplication:

Utilitybillpayments
EqualMonthlyInstallments(EMI)
Governmenttaxpayments
Governmentlicensefees
Insurancepremium
Mortgagepayments
Club/Associationsubscriptions

OriginatingBank

ReceivingBank

BEFTN

TK

TK

TK
Credit

Debit
Receiver

Originator
Figure3:EFTDebitTransactionsFlow

AtypicaltransactionasitflowsthroughtheEFTNetworkmightfollowthepathdescribedbelow:
TheOriginatoranditsbank(OB)determinebyagreementthathowtheinformationwillbedelivered
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
communicationline.
TheOBgenerallyremovesonusentries(ifany)andtransmitstheremainingentriestotheBEFTN
within the preset timeline. An onustransaction 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
BEFTNbutinsteadmaybesimplyretainedbythebankandpostedtotheappropriateaccount.
The BEFTN will sort the entries by Receiving Bank (RB) routing number and transmit the payment
informationtotheappropriateRBforposting.
Onsettlementdate/time,BEFTNwillcalculatethenetsettlementfigureforeachparticipatingbank
andthesettlementwilltakeplaceatthebooksofaccountsofBangladeshBank.

4. CONSUMERVS.CORPORATEPAYMENTS
EFT transactions are typically categorized as either consumer payments, Government payments or
commercialpayments.Thesetransactionsaredefinedinaccordancewiththerelationshipofparties
involvedinthetransactionandthetypeofreceiveraccount.
Consumer payments that could be made via the EFT network include credit applications such as
payroll,dividend,interestandannuitypaymentsandsoon.ConsumerEFTdebitapplicationsinclude
thecollectionofutilitybills,insurancepremiums,loaninstallmentsandotherrecurringobligations.
Corporate EFT applications include cash collection and disbursement, corporate trade payments,
government. tax payments etc. Cash collection and disbursement allows companies to achieve
efficiencyincashmanagementthroughintracompanytransferoffunds.Corporatetradepayments
enable corporations to exchange both data and funds with trading partners, facilitating an
automatedprocessofupdatingtheiraccountsreceivableandaccountspayablesystems.
5. PAYMENTAPPLICATIONS
The BEFTN will support a variety of payment applications. An Originator initiating entries into the
systemwillcodetheentriesinsuchamannerastoindicatethetypeofpayment,suchasadebitora
credit,andwhetheranentryisaconsumerorcorporateinnature.EachEFTapplicationisidentified
and recognized by a specific threedigit 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
paymentrelated information relevant to the application. Following is a list of SEC codes and the
differentproductseachcodesupports.
I.ConsumerApplications

CIE Customer Initiated Entry: Customer initiated entries are limited to credit applications
wheretheconsumerinitiatesthetransferoffundstoacompanyorpersonforpaymentoffunds
owed to that company or person, typical example of these entries are utility bill and other
Internetbankingproductpayments.

PPDPrearrangedPaymentandDepositEntry

DirectDeposit:Directdepositisacreditapplicationthattransfersfundsintoaconsumersaccount
atthereceivingbank.Thefundsbeingdepositedcanrepresentavarietyofproductssuchaspayroll,
remittances,interest,pension,dividendsand/orrefunds,etc.
PreauthorizedBillPayment:Apreauthorizedpaymentisadebitapplication.Companieswithexisting
relationship with the customers may participate in the EFT through the electronic transfer (direct
debit)ofbill payment entries.Throughstandingauthorizations,theconsumergrantsthe 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
wheretheamountdoesvary,suchasutilitypayments.
II.CorporateApplications

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 standalone fund transfer between corporate or
government entities, or it can support a limited disclosure of information when the funds are
beingtransferredbetweenorganizations(i.e.sisterconcerns)underthesamegroup.

CTXCorporateTradeExchange:Thisapplicationsupportsthetransferoffunds(debitorcredit)
withinatradingpartnerrelationshipinwhichbusinesspaymentremittanceinformationissent
withthefundstransfer.Thepaymentrelatedinformationisplacedinmultipleaddendarecords

inaformatagreedtobythepartiesandBEFTN.
III.OtherApplications

ADV Automated Accounting Advice: This SEC Code represents an optional service to be
providedbyBEFTNthatidentifiesautomatedaccountingadvicesofEFTaccountinginformation
in machinereadable format to facilitate the automation of accounting information for
ParticipatingBanks.

6. SETTLEMENTANDPOSTING
Settlementistheactualtransferofthefundsbetweenparticipatingbankstocompletethepayment
instructionofanEFTentry.
The transactions processed by the BEFTN will affect the accounts of the concerned banks
maintainingaccountswithBBattheendofeachprocessingcycle.
Settlementwillbecompletedusingthefollowingprocessingschedule:

ProcessingWindow

ItemSubmission

Returns

Settlement

NormalProcessing

00:0024:00hrs

AsprovidedinBEFTN
Rules

10:00hrsNextDay

CutOffs

Settlementandprocessingsessionsmaybereviewedandcommunicatedtomemberbanksbythe
ClearingHouse(BACH)authorityfromtimetotime.
The following are the three main participants and their responsibilities concerning settlement and
posting.

OriginatingBank:SettlementwiththeOBforentriesoriginatedwillfollowthesameprocedures
usedforsettlementofentriesreceived.Ifthescheduledsettlementdateofacreditentryisnot
a banking day for the OB, but the BB office is open, then the settlement will occur on the
scheduleddate.
SpecificproceduresandtimingofsettlementbetweentheOBandtheoriginatoraresolelyatthe
discretionoftheOBandtheoriginatorandtherefore,governedbyagreementbetweenthem.It
istheOBsresponsibilitytomonitorthecreditworthinessofitscorporatecustomerstoensure
thattheOBsriskinoriginatingEFTpaymentsismanagedefficiently.

EFT Operator (BEFTN): BEFTN will calculate net settlement figures for each participating bank.
BEFTNwillalsoprovideinformationtoparticipatingbanksontheamountsthatwillbesettled
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)ofBangladeshBank.

ReceivingBank(RB)
a) Posting:TheRBisresponsibleforpostingentriesandforprovidingfundsavailability,bothof
whicharedeterminedbythesettlementdateinthebatchheaderrecord.
EFTDebitswillbedeliveredtoaRBnotearlierthanonebankingdaypriortothesettlement
date.Theruleclearlymentionsthatdebitentriescannotbepostedpriortothesettlement
date.
Ifthe RBisclosedforbusinessonthescheduledsettlement dateofadebit entry,butthe

BEFTNisopen,theRBwillbedebitedonthescheduledsettlementdateunlessithasadvised
theBEFTNtodelaysettlementtothenextbusinessdayoftheRB.IfBEFTNagreestodelay
settlement,theRBmustpayforanycostsforfloatresultingfromthedeferralofsettlement.
EFTCreditswillbedeliveredtoaRBnotearlierthanoneworkingdaypriortothesettlement
date.
b) Settlement
Settlement between the originator and the OB is governed by agreement. Settlement
betweentheRBandthereceiverisdeterminedbytheseRules.
If BEFTN determines that the entrycannot be settled on the effective entry date due to a
staledate,weekend,orholiday,theBEFTNauthoritywillinserttheJuliandateofthenext
businessdayintothesettlementdatefiled,reflectingthatsettlementwilloccuronthatday.

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

BEFTN may provide EFT settlement information in a machinereadable format to

facilitatetheautomationofsettlementaccountingforcorrespondentbanks.

Settlement totals should be balanced daily against totals posted to the participating
banks customer accounts and against any rejects that may occur. Rejects and other
differencesmustberesolvedimmediately.

EFT settlement procedures are the same for consumer and corporate transactions. In
view of the largevalue payments that flow through the EFT network for corporate
customers, participating banks should have internal procedures in place to monitor
largevaluesettlementstotals.

7. LEGALFRAMEWORK
The EFT process operates from beginning to end through a series of legal agreements. Before any
transactionisinitiatedviaEFTnetwork,theoriginatorandOBexecuteanagreementtouseBEFTNto
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
accountabilityforproceduresrelatedtocertainapplication(s).
WhilethisBEFTNRulebookistheprimarydocumentaddressingtherulesandtheregulationsforthe
activities of the EFT network, Governments EFT transactions may be governed by other codes of
conductbuttheymustaccommodatetheprovisionslaiddownintheseRules.

Otherlaws/regulationsthathaveadirectbearingonEFToperationarelistedasunder:

BangladeshBankOrder,1972(Amended2003)
TheBanksCompaniesAct,1991
MoneyLaunderingPreventionAct,2009
InformationandCommunicationTechnologyAct,2006.
TheBankruptcyAct,1997
TheForeignExchangeGuidelines,Volume1&2.
ForeignExchangeRegulationAct,1947.
TheBangladeshTelecommunicationAct,2001.

AntiTerrorismAct2009
BangladeshPaymentandSettlementSystemsRegulations,2009

ARTICLEONE
GENERAL

SECTION1.1ApplicationofRules
TheserulesapplytoallentriesandentrydatatransmittedthroughBEFTN,exceptwheresuperseded
byoperatingrulesbywhichanOBandRBhaveagreedtobebound.
SECTION1.2CompliancewithRules
EachParticipatingBankmustagreetocomplywiththeseRulesandwarrantsthatitislegallyableto
complywithallapplicablerequirementsoftheseRules.
1.2.1Compensation
ThesettlementofclaimsforcompensationbetweenParticipatingBankswillbegovernedby
the procedures contained in the Bangladesh Automated Clearing House (BACH) Rules on
Compensation.
1.2.2DisputeResolution
The settlement of disputes arising under these Rules between Participating Banks will be
governedbytheprocedurescontainedintheBangladeshAutomatedClearingHouse(BACH)
DisputeResolutionProcedures.
SECTION1.3ExcusedDelay
DelaybyaParticipatingBankortheBEFTNbeyondthetimelimitsprescribedorpermittedbythese
Rulesisexcusedifthedelaywascausedbytheinterruptionofcommunicationorcomputerfacilities,
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,
provideditexercisessuchdiligenceasthecircumstancesrequire.
SECTION1.4DaysonWhichInstitutionorFacilityisClosed
Any entry or entry data required by these Rules to be made available or transmitted by a
ParticipatingBankortheBEFTNonorbyadaythatisnotaBankingdayforboththesendingparty
andreceivingpartymaybemadeavailableortransmittedonthenextdaythatisaBankingdayfor
boththesendingandreceivingparties.Thisruleonlyapplieswhereanentrywillbereceivedonthe
samedayitistransmitted.
SECTION1.5Records
1.5.1RecordsofEntries
Each Participating Bank must retain records of all entries, including return and adjustment
entries,transmittedfromortotheBEFTN.Theserecordsmustberetainedforsixyearsfrom
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
reproductionoftheinformationrelatingtotheentry.
1.5.2RecordRetention
Any agreement, authorization, written statement, or other record required by these Rules
9

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,whetherbytransmission,printing,orotherwise.
1.5.3ElectronicRecordsPermitted
Anyagreement,authorization,writtenstatement,orotherrecordrequiredbytheseRulesto
beinwritingmayinsteadbeinelectronicform.Anyrecordthatisrequiredtobesignedor
similarly authenticated may be signed with an electronic signature in conformity with the
termsoftheInformationTechnologyAct2006andinamannerthatevidencestheidentity
ofthepersonwhosignedandthatpersonsassenttothetermsoftherecord.
SECTION1.6ChoiceofLaw
TheserulesandtherightsandobligationsofapartywithregardtoEFTentriesshallbeconstruedin
accordancewithandgovernedbythelawsofThePeople'sRepublicofBangladesh,unlessotherwise
providedinanagreementofsuchparty.

10

ARTICLETWO
ORIGINATIONOFENTRIES

SECTION2.1PrerequisitestoOrigination
The following must occur before an Originator may initiate the first credit or debit entry to a
ReceiversaccountwithaRB:
2.1.1OriginatorAuthorizationandAgreement
TheOriginatorhasauthorizedtheOBtotransmit,andtocreditordebittheamountof,one
or more entries to the Receivers account. For all entries, the Originator and OB have
enteredintoanagreementunderwhichtheOriginatoragreestobeboundbytheseRulesas
ineffectfromtimetotimeandacknowledgesthatentriesmaynotbeinitiatedthatviolate
thelawsofThePeople'sRepublicofBangladesh.
2.1.2ReceiverAuthorizationandAgreement
TheReceiverhasauthorizedtheOriginatortoinitiatetheentrytotheReceiversaccount.In
thecaseofdebitentriestoacommercialaccount,theReceiverhasanagreementwiththe
OriginatorunderwhichtheReceiverhasagreedtobeboundbytheseRulesasineffectfrom
timetotime.InthecaseofdebitentriestoaConsumerAccount,theauthorizationmustbe
inwritingandsignedorsimilarlyauthenticatedbytheconsumer.Thesimilarlyauthenticated
standard permits signed, written authorizations to be provided electronically. The writing
andsignaturerequirementsaresatisfiedbycompliancewiththeInformationTechnologyAct
2006 (as contracts or other records created, generated, sent, communicated, received, or
storedbyelectronicmeans)andelectronicsignatures.Electronicsignaturesinclude,butare
not limited to, digital signatures and security codes. The authorization process must
evidence both the consumers identity and his assent to the authorization. To meet the
requirementthatanauthorizationbeinwriting,anelectronicauthorizationmustbeableto
bedisplayedonacomputerscreenorothervisualdisplaythatenablestheconsumertoread
thecommunication.Theauthorizationalsomustbereadilyidentifiableasanauthorization,
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
maybeprovidedorallyorbyothernonwrittenmeans.
2.1.3ExceptiontoAuthorizationRequirement
IfboththeOriginatorandReceiverarenaturalpersons,noauthorizationbytheReceiveris
required for credit entries, and no warranty with respect to that authorization is made by
theOB.Theprovisionsofsection3.3.3(RecordofAuthorization),andsubsection4.1.1(Right
to Information Regarding Entries) are not applicable to the entries described in this
subsection2.1.3.
2.1.4NoticebyOB
In the case of a credit entry, the OB shall have provided the Originator with notice of the
following:
(1)theentrymaybetransmittedthroughtheBEFTN;

11

(2)therightsandobligationsoftheOriginatorconcerningtheentryshallbegovernedbyand
construedinaccordancewiththelawsofThePeople'sRepublicofBangladesh;
(3)iftheRBdoesnotreceivesuchpaymentfortheentry,theRBisentitledtoarefundfrom
theReceiverintheamountofthecredittotheReceiversaccount,andtheOriginatorwill
notbeconsideredtohavepaidtheamountofthecreditentrytotheReceiver.
ThisnoticemaybeincludedaspartofanagreemententeredintobytheOriginatorbinding
theOriginatortotheseRules,oritmaybeprovidedtotheOriginatorseparately.
2.1.5NoticebyRB
Inthecaseofacreditentry,theRBhasprovidedtheReceiverwithnoticeofthefollowing
information:
(1)therightsandobligationsoftheReceiverconcerningtheentryshallbegovernedbyand
construedinaccordancewiththelawsofThePeople'sRepublicofBangladesh;
(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
settlementthroughtheBangladeshBank;
(3)iftheRBdoesnotreceivesuchpaymentfortheentry,theRBisentitledtoarefundfrom
theReceiverintheamountofthecredittotheReceiversaccount,andtheOriginatorwill
notbeconsideredtohavepaidtheamountofthecreditentrytotheReceiver;and
(4) these Rules do not require the RB to provide the Receiver with notice that the RB has
receivedtheentryunlesstheRBhasagreedtodoso.
2.1.6OBExposureLimits
InthecaseofanentryinitiatedbyanOriginatorthatisnotanaturalperson,theOBhas(1)
establishedanexposurelimitforthatOriginator,(2)implementedprocedurestoreviewthat
exposurelimitperiodically,(3)implementedprocedurestomonitorentriesinitiatedbythat
Originatorrelativetoitsexposurelimitacrossmultiplesettlementdates.

SECTION2.2WarrantiesandLiabilitiesofOriginatingBanks
2.2.1Warranties
EachOBsendinganentrywarrantsthefollowingtoeachRBandtheBEFTN:
2.2.1.1AuthorizationbyOriginatorandReceiver
Each entry transmitted by the OB to BEFTN is in accordance with proper
authorizationprovidedbytheOriginatorandtheReceiver.
2.2.1.2TimelinessofEntries
Each credit entry is timely, and each debit entry is for an amount which on the
SettlementDatewillbedueandowingtotheOriginatorfromtheReceiver,isfora
sum specified by the Receiver to be paid to the Originator, or is to correct a
previouslytransmittederroneouscreditentry.
2.2.1.3ComplianceWithOtherRequirements
All other applicable requirements of section 2.1 (Prerequisites to Origination)
concerningtheauthorizationofanentryhavebeensatisfied,theentryhasnotbeen
12

reinitiated in violation of section 2.7 (Reinitiation of Returned Entries by

Originators),andtheentryotherwisecomplieswiththeseRules.
2.2.1.4RevocationofAuthorization
AtthetimetheentryistransmittedtotheBEFTN,theOriginatorsauthorizationhas
not been revoked, the agreement between the OB and the Originator concerning
theentryhasnotbeenterminated,andneithertheOBnortheOriginatorhasactual
knowledgeoftherevocationoftheReceiversauthorizationoroftheterminationof
thearrangementbetweentheRBandtheReceiverconcerningtheentry.
2.2.1.5TerminationofAuthorizationbyOperationofLaw
AtthetimetheentryisprocessedbyaRB,theauthorizationforthatentryhasnot
beenterminated,inwholeorinpart,byoperationoflaw.Thissubsectionshallnot
apply if the RB has actual knowledge of the circumstances giving rise to such
terminationatthetimeitprocessestheentryandtheOBdoesnothavesuchactual
knowledge.
2.2.1.6TransmittalofRequiredInformation
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
requirementsofsection4.5(PeriodicStatements)exceptforinformationwithinthe
purviewoftheRBsrelationshipwiththeReceiver.Informationtransmittedwithan
entry is paymentrelated and conforms to the requirements of Appendix Two
(BEFTNRecordFormatSpecifications).
2.2.1.7ReclamationEntries
(a)Inthecaseofareclamationentryinitiatedpursuanttosection2.5(Reclamation
ntries)orawrittendemandforpaymentinitiatedpursuanttosection4.7(Liabilityof
RBforBenefitPayments),allinformationisaccurateandappliestotheReceiverand
account identified in the reclamation entry or written demand; (b) Each such
reclamationentryorwrittendemandforpaymentfallswithinthetimerequirements
ofsection4.7.4(Timing),hasbeenproperlyauthorizedbytheintendedReceiverof
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
restrictiononthenumberofpartieshavinganinterestintheaccount.
2.2.1.8CorrespondentBank
An entry containing the routing number of an OB which is transmitted to the EFT
OperatorbyanothermemberbanktotheEFTOperatoronitsbehalfistransmitted
pursuant to an agreemententered into between the OB and that service provider
banktotransmittheentry.
2.2.2Limitation
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.

13

2.2.3LiabilityforBreachofWarranty
EachOBbreachinganyoftheprecedingwarrantiesshallindemnifyeveryRBandtheBEFTN
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
creditingoftheentrytotheReceiversaccount.Thisindemnityincludes,withoutlimitation,
any claim, demand, loss, liability, or expense based on the ground that the debiting of an
entrytoanaccountresulted,eitherdirectlyorindirectly,inthereturnofoneormoreitems
orentriesoftheReceiverduetoinsufficientfunds.Thisindemnityalsoincludes,inthecase
of a Consumer Account, without limitation, any claim, demand, loss, liability, or expense
basedonthegroundthatthefailureoftheOBtocomplywithanyprovisionoftheseRules
resulted,eitherdirectlyorindirectly,intheviolationbyaRBofanyapplicablelaw.
SECTION2.3ReversingFiles
2.3.1GeneralRule
IfanOriginator,OB,orBEFTNhasmistakenlyinitiatedaduplicatefileorafileinwhicheach
entryoreachentryinoneormorebatchescontainserroneousdata,andnorighttorecall
thoseentriesotherwiseexistsundertheseRules,theOriginator,OB,orBEFTNmayinitiatea
file of entries (referred to as a reversing file) in accordance with Appendix Two (BEFTN
RecordFormatSpecifications)andthissection2.3toreverseeachentryoftheduplicateor
erroneousfileorbatch(es).
2.3.2LimitationsonInitiationofReversingFiles
Eachreversingfilemustbeinitiatedinsuchtimeastobetransmittedormadeavailableto
theRB(s)withinfiveBankingdaysaftertheSettlementDateoftheduplicateorerroneous
fileorbatch(es).InthecaseofareversingfileinitiatedbyanOriginatororOB,thefilemust
betransmittedtotheBEFTNwithin24hoursofthediscoveryoftheduplicationorerror.In
the case of a reversing file initiated by the BEFTN, the file must be transmitted to the
appropriateRBwithin24hoursofthediscoveryoftheduplicationorerror.
2.3.3NotificationbyBEFTNAuthority
Atorpriortothetimeofinitiation,theBEFTNAuthorityinitiatingareversingfileshallnotify
eachRBandeachOBdirectlyconcernedoftheduplicationorerror.
2.3.4CorrectingFiles
Areversingfiletocorrectanerroneousfileorbatchmustbeaccompaniedbyafile(referred
toaseachOBorBEFTNAuthoritythatinitiatesareversingorcorrectingfileshallindemnify
every Participating bank from and against any and all claim, demand, loss, liability, or
expense,includinglegalfeesandcosts,thatresultdirectlyorindirectlyfromthedebitingor
crediting of any entry in the file to the Receivers account. Each OB also shall indemnify
every RB from and against any and all claim, demand, loss, liability, or expense, including
legalfeesandcosts,resultingdirectlyorindirectlyfromthecreditingordebitingofanyentry
containedinareversingorcorrectingfileinitiatedbyanOriginatorthroughtheOB.
2.3.5Indemnification
EachOBthatinitiatesareversingorcorrectingfileshallindemnifyeveryParticipatingbank
from and against any and all claim, demand, loss, liability, or expense, including legal fees
andcosts,thatresultdirectlyorindirectlyfromthedebitingorcreditingofanyentryinthe
filetotheReceiversaccount.EachOBalsoshallindemnifyeveryRBfromandagainstany
and all claim, demand, loss, liability, or expense, including legal fees and costs, resulting

14

directlyorindirectlyfromthecreditingordebitingofanyentrycontainedinareversingor
correctingfileinitiatedbyanOriginatorthroughtheOB.
2.3.6InapplicableProvisions
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
(ConsumerAccountsNoticebyOriginatortoReceiverofVariableDebits)donotapply.
Acorrectingfile,whichcontainscorrectinformation.Thecorrectingfilemustcomplywith
therequirementsofAppendixTwo(BEFTNRecordFormatSpecifications).
SECTION2.4ReversingEntries
2.4.1GeneralRule
An Originator may initiate an entry (referred to as a reversing entry) to correct an
erroneous credit or debit entry previously initiated to a Receivers account. The reversing
entrymustbetransmittedtotheBEFTNinsuchtimeastobetransmittedormadeavailable
to the RB by midnight of the fifth Banking day following the Settlement Date of the
erroneousentry.Forthissection2.5only,anerroneousentryisdefinedasanentrythat(1)
isaduplicateofanentrypreviouslyinitiatedbytheOriginatororOB;(2)orderspaymentto
or from a Receiver not intendedto be credited or debited by the Originator; or (3) orders
paymentinanamountdifferentthanwasintendedbytheOriginator.TheOriginatormust
notify the Receiver of the reversing entry and the reason for the reversing entry no later
thantheSettlementDateofthereversingentry.
2.4.2Indemnification
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,
includinglegalfeesandcosts,thatresultdirectlyorindirectlyfromthedebitingorcrediting
ofthereversingentrytotheReceiversaccount.EachOBalsoshallindemnifyeveryRBand
theBEFTNAuthorityfromandagainstanyandallclaim,demand,loss,liability,orexpense,
includinglegalfeesandcosts,thatresultdirectlyorindirectlyfromthecreditingordebiting
ofareversingentryinitiatedbyanOriginatorthroughtheOB.
2.4.3InapplicableProvisions
For a reversing entry complying with the requirements of Section 2.5, the provisions of
sections2.1.2(ReceiverAuthorizationandAgreement),2.2.1.1(AuthorizationbyOriginator
and Receiver), 2.2.1.4 (Revocation of Authorization), 2.2.1.5 (Termination of Authorization
by Operation of Law), and 3.3 (Consumer AccountsNotice by Originator to Receiver of
VariableDebits)donotapply.
SECTION2.5ReclamationEntries
2.5.1GeneralRule
AnOriginatororOBmayinitiateareclamationentryinaccordancewiththerequirementsof
Section 2.6, section 4.7 (Liability of RB for Benefit Payments), and Appendix Two (BEFTN
RecordFormatSpecifications).

15

2.5.2Definition
Areclamationentrymustcontainanamountequaltoorlessthanthepension,annuity,or
otherbenefitpaymenttowhichthereclamationentryrelates,asprovidedforinsection4.7
(LiabilityofRBforBenefitPayments).
2.5.3InapplicableProvisions
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 AccountsNotice
byOriginatortoReceiverofVariableDebits)donotapply.
SECTION2.6ReinitiatingReturnedEntriesbyOriginators
Anentrythathasbeenreturnedmaynotbereinitiatedunless(1)thedebitentryhasbeenreturned
for insufficient or uncollected funds; (2) the entry has been returned for stopped payment and
reinitiatingthereturnentryhasbeenauthorizedbytheReceiver;or(3)theOBhastakencorrective
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.
SECTION2.7MediaandFormatSpecificationRequirements
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
FormatSpecifications).
SECTION2.8ReleaseofInformation
EachOBagreesthattheBEFTNmayreleasetoany/concerneddepartmentofBangladeshBankdata
regardingEFTreturnentriestransmittedtoorbytheOB.

16

ARTICLETHREE
OBLIGATIONSOFORIGINATORS

SECTION3.1General
Inadditiontotherequirementsofsection2.1(PrerequisitestoOrigination)concerningtheinitiation
ofentries,anOriginatormustcomplywiththerequirementscontainedwithinthisArticleThree.
SECTION3.2ConsumerAccountsNoticebyOriginatortoReceiverofVariableDebits
3.2.1NoticeofChangeinAmount
IftheamountofadebitentrytobeinitiatedtoaConsumerAccountdiffersfromtheamount
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
amountoftheentryandthedateonorafterwhichtheentrywillbedebited.
3.2.2ReceiversElection
If the Originator informs the Receiver of the Receivers right to receive notification
concerning a change in the amount of a debit entry, the Receiver may choose to receive
noticeonlyiftheamount oftheentryfallsoutsidea specifiedrangeoriftheentrydiffers
fromthemostrecententrybymorethananagreeduponamount.
3.2.3NoticeofChangeinScheduledDebitingDate
IfanOriginatorchangesthedateonorafterwhichentriestobeinitiatedbytheOriginator
are scheduled to be debited to a Receivers account, the Originator shall send to the
Receiver written notification of the new date on or after which entries initiated by the
OriginatorarescheduledtobedebitedtotheReceiversaccount.Suchnotificationshallbe
sent within not less than seven calendar days before the first entry to be affected by the
changeisscheduledtobedebitedtotheReceiversaccount.Forpurposesofthissubsection
3.2.3,thevariationindebitingdatesduetoholidaysisnotconsideredtobechangesinthe
scheduleddates.

SECTION3.3RecordofAuthorization
AnOriginatormustretaintheoriginaloranimagecopyofeachauthorizationofaReceiverfortwo
years from the termination or revocation of the authorization. At the request of its OB, the
OriginatormustprovidetheoriginalorcopyoftheauthorizationtotheOBforitsuseorfortheuse
of a RB requesting the information pursuant to subsection 4.1.1 (Right to Information Regarding
Entries).

17

ARTICLEFOUR
RECEIPTOFENTRIES

SECTION4.1GeneralRightsandObligationsofRB
4.1.1RighttoInformationRegardingEntries
PriortoactingasaRBforaReceiver,theRBmayrequest,inwriting,thatanOBprovidea
copyoftheReceiversauthorizationforanyentriesotherthancreditentries.
UponreceiptoftheRBswrittenrequest,theOBmustobtaintheoriginaloracopyofthe
Receivers authorization from the Originator in accordance with section 3.4 (Record of
Authorization)andprovideittothe RBwithin tenBankingdays. AnOBmust providesuch
authorizationwithoutcharge.TheRBmustnotrequiretheOriginatortoprovideanyother
information concerning the Receiver or any entry to be initiated by the Originator to the
Receiversaccount.
Thissubsection4.1.1doesnotapplytoentriesiftheOBandRBarepartiestoanagreement
(otherthantheseRules)fortheprovisionofservicesrelatingtosuchentries.
4.1.2ObligationtoAcceptEntries
SubjecttoitsrighttoreturnorrejectentriesundertheseRules,aRBmustacceptcreditand
debit entries that comply with these Rules and are received with respect to any account
maintainedwiththatRB.
4.1.3RelianceonAccountNumbersforPostingofEntries
IftheaccountnumberandthenameoftheReceivercontainedinanentrydonotrelateto
thesameaccount,theRBmayrelysolelyontheaccountnumbercontainedintheentryfor
purposesofpostingtheentrytotheReceiversaccount.

SECTION4.2WarrantiesofReceivingBanks
EachRBwarrantstoeachOBandtheBEFTNthatithasthepowerunderapplicablelawtoreceive
entriesasprovidedintheseRulesandtocomplywiththerequirementsoftheseRulesconcerning
RBsandParticipatingBanks.AnyRBbreachinganywarrantyunderthissection4.2shallindemnify
each OB, BEFTN Authority from and against any and all claim, demand, loss, liability, or expense,
includinglegalfeesandcosts,resultingdirectlyorindirectlyfromthebreachofwarranty.
SECTION4.3AvailabilityofEntries,CreditingandDebitingofEntries
4.3.1AvailabilityofCreditEntriestoReceivers
SubjecttoitsrighttoreturnorrejectentriesinaccordancewiththeseRules,eachRBmust
maketheamountofeachcreditentryreceivedfromtheBEFTNavailabletotheReceiverfor
withdrawalorcashwithdrawalnolaterthantheSettlementDateoftheentry.

18

4.3.2TimeofDebitingofEntries
ARBmustnotdebittheamountofanyentrytoaReceiversaccountpriortotheSettlement
Date of the entry, even if the effective entry date of the entry is different from the
SettlementDateoftheentry.
4.3.3ProvisionofPaymentRelatedInformationtoReceiver
Upon the request of the Receiver, a RB must provide to its Receiver all PaymentRelated
InformationcontainedwithinanyAddendaRecordstransmittedwiththeentries(especially
CTXentry).TheRBmustprovidethisinformationtoitsReceiverontheSettlementDateof
theentry.
4.3.4CreditingofOriginatorsAccountsbyReceiver
AReceivermustcredittheOriginatorwiththeamountofanentrycreditedtotheReceivers
accountasoftheSettlementDate.TheReceivershallhaveareasonableperiodoftimeafter
the entry is credited to the Receivers account to post the amount of the credit to the
OriginatorsaccountorreturntheentrytotheRB.Forpurposesofthissection,aReceiver
shallbeconsideredtoactwithinareasonableperiodoftimeiftheReceiverpoststhecredit
orreturnstheentrynolaterthanthetimeatwhichtheReceiverwouldusuallycompletethe
process of posting credits resulting from payments received to its customers accounts or
returningthesepayments.AReceiverthatreturnsanentryaccordingtotherequirementsof
thissubsection4.4.4isnotconsideredtohaveacceptedtheentry.
4.3.5RightsofReceiverUponUnauthorizedDebittoItsAccount
A Receiver or other person whose account is debited by an entry which is, in whole or in
part,notauthorizedbysuchpersonshallhaverights,includingtherighttohavetheaccount
recredited as provided by law or agreement. Except as provided for in subsection 7.6.7
(WaiverofRighttoRecredit),theseRulesshallnotprovidefororrestrictanysuchrights.
4.3.6RelianceonStandardEntryClassCodes
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
Rulesforthattypeofentry.
4.3.7ReimbursementofRB
AcreditentrygiventotheReceiverbytheRBasprovidedinsubsection4.4.1(Availabilityof
CreditEntriestoReceivers)isprovisionaluntiltheRBhasreceivedfinalsettlementthrough
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
havepaidtheReceivertheamountoftheentry.
SECTION4.4PeriodicStatements
ARBmustsendormakeavailabletoeachofitsReceiversinformationconcerningeachcreditand
debit entry to a Consumer Account of the Receiver in accordance with Appendix Four (Minimum
DescriptionStandards).

19

SECTION4.5NoticetoReceiver
A RB is not required to notify a Receiver of receipt of an entry to its account unless otherwise
providedfor inanagreement betweentheRBand Receiverorrequiredby governmentstatuteor
regulationwhichcannotbevariedbytheseRulesorbyagreementoftheparties.
SECTION4.6ReleaseofInformation
Each RB agrees that BEFTN Authority may release information to any concerned department of
BangladeshBankregardingEFTreturnentriestransmittedtoorbytheRB.
SECTION4.7LiabilityofRBforBenefitPayments
4.7.1LiabilityofRB
IfaReceiverhasdiedandtheReceiversrighttoreceiveoneormorepension,annuity,or
otherbenefitpaymentsbycreditentryhasterminatedbeforethereceiptbytheRBofone
ormorecreditentriestotheReceiversaccountrepresentingthosepayments,theRBmay
beliabletotheOriginatorfortheamountofthoseentriescreditedtotheReceiversaccount
if neither the Receivers estate nor any other holder of the account is entitled to the
payments.TheliabilityaRBwouldincurunderthissubsection4.7.1islimitedasprovidedin
thissection4.7.
4.7.2AmountofRBLiability
ARBsliabilityunderthissection4.7shallbethelesserof(1)theamountofanypaymentsto
whichtheReceiverwasnotentitled,or(2)theamountintheReceiversaccountatthetime
the RB receives (i) a reclamation entry initiated by the OB pursuant to section 2.6
(ReclamationEntries)andnotreturnedbytheRBor(ii)awrittendemandforpaymentfrom
theOBorOriginatorpursuanttosubsections4.7.3(DemandforPayment)and4.7.4(Timing)
and has a reasonable opportunity to act upon such demand. A claim or demand by an
Originator(orOBontheOriginatorsbehalf)willbesubordinatetoclaimsorpotentialclaims
ofTheGovernmentofthePeople'sRepublicofBangladesh.TheOriginatormustreimburse
theRBforanypaymentsmadetotheOriginatorpursuanttothissection4.7thataresubject
toasubsequentclaimofTheGovernmentofthePeople'sRepublicofBangladesh.
4.7.3DemandforPayment
ARBwillhavenoliabilityunderthissection4.7unlessanduntilitreceives(1)areclamation
entryinitiatedbytheOBpursuanttosection2.6(ReclamationEntries)andnotreturnedby
the RB, or (2) a written demand for payment from the OB or Originator. The reclamation
entryorwrittendemandforpaymentmustidentifythenameoftheReceiver,theaccountat
the RB credited on the Receivers behalf, and the exact amount and approximate date of
initiationforeachentryinvolved.
4.7.4Timing
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
paymentwithin15Bankingdaysafteritreceivesthereturnedreclamationentry.
4.7.5AlterationbyAgreement
NotwithstandinganyotherprovisionoftheseRules,theliabilityprovisionscontainedwithin
thissection4.7maybealtered,amended,orsupersededbyawrittenagreementbetween

20

theOriginatorandRBonlyiftheagreementclearlyandconspicuouslystatesonitsfacethat
it is a master agreement, that both the Originator and RB consider it to be a master
agreement,andthatitis applicabletoallpaymentssubjecttothissection4.7sentbythe
OriginatortotheRBforthebenefitofallReceivershavingaccountsattheRB.Noprovision
oftheseRulespreventsaRBfromexpresslyagreeinginamasteragreementthattheliability
provisions of this section 4.7 may be altered, amended, or superseded on a Receiverby
Receiverbasis.

21

ARTICLEFIVE
RETURN,ADJUSTMENT,CORRECTION,ANDACKNOWLEDGMENT
OFENTRIESANDENTRYINFORMATION

SECTION5.1ReturnofEntries
5.1.1RighttoReturnEntries
Exceptasotherwiseprovidedforinsubsection5.1.3(RestrictionsonRighttoReturn),aRB
mayreturnanentryforanyreason.
5.1.2RequirementsofReturns
Each return entry must comply with the requirements of Appendix Five (Return Entries).
Exceptasotherwiseprovidedinthissection5.1,subsection5.3.2(OBandOriginatorAction
onNotificationofChange),eachreturnentrymustbereceivedbytheBEFTNbyitsdeposit
deadlinefor thereturnentrytobe madeavailabletotheOBnolaterthantheopeningof
businessonthesecondBankingdayfollowingtheSettlementDateoftheoriginalentry.For
purposesoftheprecedingsentence,thetermsecondBankingdayshallrefertothesecond
BankingdayoftheBEFTN,andthetermSettlementDateoftheoriginalentryshallreferto
theSettlementDateoftheoriginalentrythatisbeingreturned.Areturnentryrelatingtoa
creditentry mustbetransmittedbytheRBtotheBEFTNiftheReceiveroftheentrydoes
nothaveanaccountwiththeRB,theReceiversaccounthasbeenclosed,ortheRBisnot
permitted by law to receive credits for the Receivers account. A return entry which is
rejected by the BEFTN Authority does not meet or extend the deadline contained in this
section5.1.
5.1.3RestrictionsonRighttoReturn
ARBmaynotreturnanentrybecauseitisacredit,debit,orzeroTakaentryorisaparticular
typeofcredit,debit,orzeroTakaentry.ARBmay,however,returnanydebitentryorany
entry received that concerns any account that is not a transaction account maintained
withthatRB.
5.1.4CreditEntriesReturnedbyReceiver
A RB may return any credit entry that is returned to it by a Receiver as provided for in
subsection4.4.4(CreditingofOriginatorsAccountsbyReceiver).TheRBmusttransmitthe
return entry to the BEFTN by midnight of the Banking day following the Banking day of
receiptbytheRBfromtheReceiver.
5.1.5ReturnofUnpostedCreditEntries
ARBmustreturnallcreditentriesthatarenotcreditedorotherwisemadeavailabletoits
ReceiversaccountsbymidnightoftheBankingdayfollowingtheSettlementDate.
5.1.6AcceptanceofReturnEntriesbyOB
An OB must accept return entries complying with Appendix Five (Return Entries) and
transmittedbytheRBwithinthetimelimitsestablishedbytheseRules.

22

5.1.7ReinitiationofReturnEntriesbyOB
An entry that has been returned may not be reinitiated unless (1) the entry has been
returnedforinsufficientoruncollectedfunds;(2)theentryhasbeenreturnedforstopped
payment and reinitiation has been authorized by the Receiver; or (3) the OB has taken
correctiveactiontoremedythereasonforthereturn.Anentrythathasbeenreturnedfor
insufficient or uncollected funds may be reinitiated no more than two times following the
returnoftheoriginalentry.
SECTION5.2DishonourofReturnEntries
5.2.1DishonourofReturnbyOB
AnOBmaydishonourareturnentry(1)ifitcansubstantiatethattheRBfailedtoreturnthe
entry within the time limits established by these Rules, thus causing either the OB or
Originatortosufferaloss,or(2)ifthereturnentrycontainsincorrectinformation,doesnot
include all information required by Appendix Five (Return Entries), or otherwise fails to
complywiththerequirementsofAppendixFive.Todishonourareturnentry,theOBmust
transmit a dishonoured return entry complying with Appendix Five to BEFTN within five
BankingdaysaftertheSettlementDateofthereturnentry.
5.2.2ContestingofDishonouredReturnsbyRB
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
dishonouredreturnentrytransmittedbytheRBandcomplyingwiththissection5.2.
5.2.3ContestingaContestedDishonouredReturn
An OB may not contest a contested dishonoured return received from a RB by reinitiating
theentry.Anyfurtheractionconcerningacontesteddishonouredreturn mustbepursued
outsideoftheBEFTNoperatingrules.
5.2.4CorrectedReturns
A RB receiving a dishonoured return entry based on a return entry containing incorrect
information,failingtocontainallinformationrequiredbyAppendixFive(ReturnEntries),or
otherwise failing to comply with the requirements of Appendix Five may transmit a
correctedreturnentrytotheBEFTNwithintwoBankingdaysoftheSettlementDateofthe
dishonouredreturnentry.Thecorrectedreturnentrymustcomplywiththerequirementsof
AppendixFiveandmustincludethedishonouredreturninformationreceivedfromtheOB.
The OB must accept a corrected return entry transmitted by a RB in accordance with this
subsection5.2.3.
SECTION5.3NotificationofChange
5.3.1NotificationsofChange;RBWarrantiesandIndemnity
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
NOCistransmittedwithintwoBankingdaysoftheSettlementDateoftheentrytowhichthe

23

NOCrelates.EachRBthattransmitsanNOCorcorrectedNOCasprovidedforinsubsection
5.4.2 (RB Action on Refused Notification of Change) warrants to each OB and the BEFTN
AUTHORITYthat(1)theinformationcontainedwithintheNOCorcorrectedNOCiscorrect,
and(2)ifthechangerelatestotheReceiversaccountnumber,theReceiverhasauthorized
thechange,ifauthorizationisrequired,andtheRBhascompliedwithanyapplicablelegal
requirementsforsuchauthorization.TheRBswarrantysupersedesandrendersinoperative
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
indemnifyeachOBandtheBEFTNAUTHORITYfromandagainstanyandallclaim,demand,
loss,liability,orexpense,includinglegalfeesandcosts,resultingdirectlyorindirectlyfrom
thebreachofwarranty.
5.3.2OBandOriginatorActiononNotificationofChange
Unless otherwise provided for in this Article Five, an OB must accept NOCs and corrected
NOCsthatcomplywiththerequirementsofAppendixSix(NotificationofChange)andthat
aretransmittedbytheRBwithinthetimelimitsestablishedbytheseRules.EachOBmust,at
aminimum,providetotheOriginatorinformationrelatingtoNOCsandcorrected NOCsin
accordancewiththerequirementsofAppendixSix.TheOriginatormustmakethechanges
specified in the NOC or corrected NOC within six Banking days of receipt of the NOC
informationorpriortoinitiatinganotherentrytotheReceiversaccount,whicheverislater.
SECTION5.4RefusedNotificationofChange
5.4.1OBRighttoRefuseNotificationofChangeEntries
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
requiredbyAppendixSix(NotificationofChange),or(3)theNOCotherwisefailstocomply
withAppendixSix.TorefuseanNOCorcorrectedNOC,theOBmusttransmitanautomated
refusednotificationofchangecomplyingwithAppendixSixtotheBEFTNwithinfifteendays
ofreceiptoftheNOCorcorrectedNOC.
5.4.2RBActiononRefusedNotificationofChange
ARBmaytransmitacorrectedNOCcomplyingwithAppendixSix(NotificationofChange)to
theBEFTNwithinfiveBankingdaysaftertheSettlementDateoftherefusedNOC.

24

ARTICLESIX
SETTLEMENTANDACCOUNTABILITY

SECTION6.1MaintenanceofCentralBankAccount
EachParticipatingBankmustmaintainanaccountwithBangladeshBank.
SECTION6.2Settlement
SettlementamongParticipatingBanksforentries,adjustmententries,andreturnentriestransmitted
inaccordancewiththeseRuleswillbeeffectedbythecreditingordebitingoftheBangladeshBank
accountsofParticipatingBanksreferredtoinsection6.1(MaintenanceofCentralBankAccounts).
SECTION6.3EffectofSettlement
SettlementofentriesdoesnotprecludeaParticipatingBankfrompursuinganyavailablelegalrights
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
limitsestablishedbytheseRules.
SECTION6.4AccountabilityforEntries
Each RB is accountable for the amount of all debit entries received that are not returned in
accordancewiththeseRules,exceptasprovidedforinsubsection5.3.2(OBandOriginatorActionon
Notification of Change). The RBs accountability under this section is not affected by the failure of
theOBtocomplywiththeprovisionsofsection5.2(DishonourofReturnEntries).
SECTION6.5EffectofRBClosingonTimeofSettlement
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
BangladeshBankthatsettlementfortheentryshouldbedeferreduntilthenextBankingday.Ifthe
RBhasprovidedsuchnoticetotheBangladeshBank,settlementforthedebitentrywilloccuronthe
nextBankingday,andtheRBshallpaythefloatchargeassessedbytheBangladeshBank.
SECTION6.6EffectofOBClosingonTimeofSettlement
IfthescheduledSettlementDateforacreditentryisnotaBankingdayfortheOBbutisadayon
whichtheapplicableofficeoftheCentralBankdescribedinsection6.1(MaintenanceofAccountsat
theCentralBank)isopen,settlementwilloccuronthescheduleddate.

25

ARTICLESEVEN
RECALL,STOPPAYMENT,RECREDIT,ANDADJUSTMENT

SECTION7.1RecallbyOBorOriginator
Except as allowed by sections 2.4 (Reversing Files), 2.5 (Reversing Entries), and 2.6 (Reclamation
Entries),neitheranOriginatornoranOBhastherighttorecallanentryorfile,torequirethereturn
oforadjustmenttoanentry,ortostopthepaymentorpostingofanentry,oncetheentryorfilehas
beenreceivedbytheBEFTN.
SECTION7.2OBRequestforReturn
AnOBmay,orallyorinwriting,requestaRBtoreturnoradjustanerroneousentryinitiatedbythe
OB.Forpurposesofthissection7.2,anerroneousentryisanentry(1)thatisaduplicateofanentry
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
differentthanwasintendedbytheOriginator.TheRBmay,butisnotobligatedto,complywithsuch
a request. The OB making such a request indemnifies the RB from and against any and all claim,
demand,loss,liabilityorexpense,includinglegalfeesandcosts,resultingdirectlyorindirectlyfrom
compliancebytheRBwithsuchrequest.
SECTION7.3OBAgreestoAcceptaCorporateDebitReturn
IfaRBreceiveswrittennotificationfromaReceiverafterthetimeforreturnhasexpired(seeArticle
Five,section5.1ReturnofEntries)thataCorporatedebitentrytotheReceiversaccountwas,in
wholeorinpart,notauthorizedbytheReceiver,theRBmaytransmitapermissiblereturnentryto
theOB,providedthattheOBagrees,eitherverballyorinwriting,toacceptthelatereturnentry.The
permissible return entry must be in the amount of the debit entry and must comply with the
requirementsofArticleFive,section5.1andAppendixFive(ReturnEntries).
SECTION7.4StopPaymentAffectingConsumerAccounts
AReceivermaystopthepaymentofadebitentryinitiatedortobeinitiatedtoaConsumerAccount
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
withinthethreeBankingdaylimitprescribedabove,and,ifithonourssucharequest,theRBhasno
resultantliabilityorresponsibilitytoanyOriginator,OB,orotherpersonhavinganyinterestinthe
entry.TheRBmayrequirethatwrittenconfirmationofaverbalstoppaymentorderbemadewithin
14 days of a verbal stop payment order, provided that the RB notifies the Receiver of this
requirementandprovidesanaddresstowhichthewrittenconfirmationshouldbesentatthetime
theverbalorderisprovided.IftheRBrequireswrittenconfirmation,theverbalstoppaymentorder
willceasetobebindingafter14days.AReceivermaywithdrawastoppaymentorderbyproviding
writtennoticetotheRB.Astoppaymentorderwillremainineffect(1)forsixmonthsfromthedate
ofthestoppaymentorder,(2)untilpaymentofthedebitentryhasbeenstopped,or(3)untilthe
Receiverwithdrawsthestoppaymentorder,whicheveroccursearliest.
SECTION7.5StopPaymentAffectingNonConsumerAccounts
AReceivermayorderitsRBtostopthepaymentofanydebitentryinitiatedortobeinitiatedtoa
nonConsumerAccountoftheReceiver.ThestoppaymentordermustbeprovidedtotheRBatsuch
timeandinsuchmannerastoallowtheRBareasonableopportunitytoactuponthestoppayment
orderpriortoactingonthedebitentry.TheRBisobligatedtocomplywithaverbalstoppayment
orderonlyforaperiodoffourteencalendardaysunlesstheorderisconfirmedinwritingwithinthat

26

14day period. A written stop payment order is effective for six months unless it is renewed in
writing.
SECTION7.6ReceiversRighttoRecredit
7.6.1ReceiversRighttoRecredit
ARBmustpromptlycredittheamountofadebitentrytoaConsumerAccountofaReceiver
if(1)theReceiversendsordeliverstotheRBawrittenstatementasdescribedinsubsection
7.6.4 (Receivers Written Statement) that the debit entry was not authorized by the
Receiver,and(2)thiswrittenstatementissentordeliveredtotheRBwithin180calendar
daysfromthedatetheRBsendsormakesavailabletotheReceiverinformationrelatingto
thedebitentryinaccordancewithsection4.5(PeriodicStatements).
7.6.2ReceiversWrittenStatement
Forallconsumerentries,aReceivermustsignorsimilarlyauthenticateawrittenstatement,
in the form required by the RB, that the debit entry for which the Receiver is seeking re
creditunderthissection7.6wasnotauthorizedbytheReceiver.
7.6.3UnauthorizedDebitEntry
Forpurposesofthissection(7.6),adebitentrywasnotauthorizedbytheReceiverif(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.4WaiverofRighttoRecredit
AnOriginatormayrequestaReceivertowaivetheReceiversrightsundersubsection4.4.5
(Rights of Receiver Upon Unauthorized Debit to Its Account) with respect to one or more
specificdebitentriesinitiatedtotheReceiversaccount.Thiswaivermust(1)beinwritingin
adocumententitledWaiverwithrespecttoprearrangeddebit,(2)specifytheamountof
each entry to which the waiver applies, (3) specify the approximate date on which each
entrywasinitiatedbytheOriginator,(4)specifytheOriginatornumberdesignatedineach
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 Receivers 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
subsection4.4.5iseffectiveforanypurpose.
7.6.5EffectofExecutionofWaiver
If a waiver complying with the requirements of subsection 7.6.4 (Waiver of Right to Re
credit)hasbeensignedbytheReceiverandreceivedbytheRBinsufficienttimeandinsuch
manner as to afford the RB a reasonable opportunity to act upon it, subsections 7.6.1
(Receivers Right to Recredit), 7.6.2 (Receivers Written Statement), and section 7.7
(AdjustmentEntries)shallnotapplytotheentryorentriestowhichthewaiverrelates.Ifan
Originatortransmitssuchawaiver,withacopy,toaRB,theRB,uponwrittenrequestofthe
Originator, must acknowledge receipt on the copy of the waiver and promptly deliver or
sendthatcopytotheOriginator.

27

7.6.6RecreditRightNotExclusive
The rights provided to the Receiver under this section 7.6 are in addition to any rights
providedunderotherapplicablelaw.
SECTION7.7AdjustmentEntries
7.7.1RBsRighttoAdjustment
Forallconsumerentries,aRBreceivingthewrittenstatementdescribedinsubsection7.6.2
(Receivers Written Statement) may transmit an adjustment entry to its BEFTN in the
amountoftheunauthorizedentryreferredtointhewrittenstatement,providedthat(1)no
error was made by the RB in the debiting of the entry to the Receivers account, (2) the
writtenstatementdescribedinsubsection7.6.2wassentordeliveredtotheRB,and(3)the
RBtransmittedtheadjustmententrytotheBEFTNbyitsdepositdeadlinefortheadjustment
entrytobemadeavailabletotheOBnolaterthantheopeningofbusinessontheBanking
dayfollowingtheonehundredeightiethcalendardayfollowingtheSettlementDateofthe
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
beensentwithinthetimelimitsdescribedabove.
7.7.2WarrantyofRB
Each RB transmitting an adjustment entry pursuant to subsection 7.7.1 (RBs 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
(ReceiversRighttoRecredit).EachRBbreachingthiswarrantyshallindemnifyeveryOBand
theBEFTNfromandagainstanyandallclaim,demand,loss,liability,orexpense,including
legalfeesandcosts,resultingdirectlyorindirectlyfromthebreachofsuchwarranty.
7.7.3CopyofWrittenStatement
Each RB initiating an adjustment entry pursuant to subsection 7.7.1 (RBs Right to
Adjustment) will provide a copy of the written statement obtained from the Receiver in
accordancewithsection7.6(ReceiversRighttoRecredit),providedsuchrequestisreceived
bytheRBwithinoneyearofthedateoftheinitiationoftheadjustmententry.
7.7.4AcceptanceofAdjustmentEntriesbyOB
EachOBmustacceptadjustmententriestransmittedtoitinaccordancewiththeseRules.

28

ARTICLEEIGHT
OBLIGATIONSOFTHEBEFTNAUTHORITY

SECTION8.1ProcessingObligation
TheBEFTNAuthoritymust,inaccordancewithAppendixTwo(BEFTNRecordFormatSpecifications):
(1) promptly process entries and entry data, insert the appropriate Settlement Date, and reject
batchesandfilesinaccordancewithsection8.3(ReturnandRejectionbyBEFTN),
(2) transmit or make available entries and entry data to Participating Banks in accordance with
agreeduponprocessinganddeliveryschedules,
(3) remakeanyfilerejectedbyaRB,
(4) total the debit and credit activity received from and transmitted to Participating Banks during
eachBankingday,and
(5) calculateandreportthesettlementamountsforeachdayforallentriesprocessedunderthese
Rules.
SECTION8.2ReturnandRejectionbyBEFTN
Ifanentryorentrydatareceivedforprocessingdoesnotmeettheacceptancecriteriasetforthin
AppendixTwo(BEFTNRecordFormatSpecifications),AppendixFive(ReturnEntries),orAppendixSix
(Notification of Change), the BEFTN must in accordance with those Appendices either return the
entryorentrydatatotheappropriateOBorrejecttheentirebatchorfilecontainingtheentryby
notifyingtheappropriateOB.
SECTION8.3OriginatorStatusCodeReview
TheBEFTNmustrevieweachbatchofentriesitreceivestoensurethattheappropriatestatuscode
pertainingtotheOriginator(theOriginatorStatusCode)isincludedinaccordancewithAppendix
Two (BEFTN Record Format Specifications). If a batch of entries contains an incorrect Originator
StatusCodeorcontainsnoOriginatorStatusCode,theBEFTNmusteitherrejectthebatchorinsert
thecorrectOriginatorStatusCode.
SECTION8.4OptionalServices
TheBEFTNmayprovideoptionalservices.Theuseoftheoptionalservicesmustnotinconvenience
oradverselyaffecttherightsofParticipatingBanksthatdonotuseoptionalservices.
SECTION8.5NonSettledEntries
If a Participating Bank is unable to meet its settlement obligations under the settlement rules
establishedbytheBangladeshBankforentriesithasoriginatedorreceived(nonsettledentries),
the BEFTN must return or reverse the nonsettled entries in accordance with sections 8.6 (Entries
OriginatedtoaRBthatCannotSettle)and8.7(EntriesReceivedfromanOBthatCannotSettle).The
BEFTNisresponsibleforestablishingthedefinitionofnonsettledentriesandtheproceduresunder
whichsettlementbalancesaretobeadjustedwithinitsownsettlementrules.
SECTION8.6EntriesOriginatedtoaRBthatCannotSettle
The BEFTN must create a return entry complying with the requirements of Appendix Five (Return
Entries) for each nonsettled entry and transmit that nonsettled entry to the OB. An OB that
receivesareturnentrycomplyingwiththerequirementsofthissection8.6mustacceptandmaynot
dishonourthatentry.TheOBmaynotreinitiateanonsettledentry.

29

SECTION8.7EntriesReceivedfromanOBthatCannotSettle
The BEFTN Authority must create a reversing entry complying with the requirements of Appendix
Two(BEFTNRecordFormatSpecifications)foreachnonsettledentryandtransmitthatnonsettled
entrytotheRB.ARBthatreceivessuchareversingentrycomplyingwiththerequirementsofthis
section8.7mustacceptandmaynotreturnthatreversingentry.
SECTION8.8RecordofEntries
TheBEFTNAuthoritymustretainarecordofallentries,returnentries,andadjustmententries(all
referredtointhissectionasentries)receivedortransmittedbyitfortwelveyearsfromthedate
ofreceiptortransmittaloftheentry.TheBEFTNmustprovideaprintoutoraccesstothearchiveof
the information relating to a particular entry if requested to do so by the Participating Bank that
originated,transmitted,orreceivedtheentry.

30

ARTICLENINE
RESPONSIBILITIESOFBANGLADESHBANKANDBEFTNPARTICIPANTS
SECTION9.1General
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
thatsendsitemstotheBangladeshBank,areceivingbankthatreceivesitemsfromtheBangladesh
Bank,anaccountholderthathasagreedtosettleforitemsunderthisArticle.AnyEFTitemthatis
sent to the Bangladesh Bank (BEFTN) for processing and settlement is subject to the provisions of
thisArticle.TheBangladeshBankprocessessuchitemsasaBEFTNoperatoranddoesnotcollect,
present,orreturnsuchitemsasacollectingorreturningbankunlessBangladeshBankchooseto
take part as a participants (OB/RB) for its own or for the governments payment processing
purpose.
SECTION9.2SendingCreditandDebitItems
9.2.1.AsendingbankthatmaintainsorusesasettlementaccountattheBangladeshBank
maysendanitemtotheBangladeshBank,providedthereceivingbankmaintainsorusesa
settlementaccountforBEFTNitemsattheBangladeshBank.
9.2.2. An item must be in the media the Bangladesh Bank prescribes and in the format
prescribedbytheapplicableBEFTNrules.
9.2.3.AsendingbankmaywiththepriorapprovalofBangladeshBankdesignateasending
point as its agent to send items to the Bangladesh Bank. It is the sending banks
responsibility to ensure that its agent complies with the sending banks obligations under
theseRules.
9.2.4. The sending bank agrees to indemnify, defend, and hold the Bangladesh Bank
harmlessagainstanyclaim,loss,cost,orexpenseresultingfrom(i)theactsoromissionsof
the sending banks agent; (ii) the Bangladesh Banks 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 attorneys fees and expenses of
litigation, except for any claim, loss, cost, or expense arising solely out of the Bangladesh
Banksfailuretoexerciseordinarycareortoactingoodfaith.
SECTION9.3SecurityProcedures
9.3.1.ThesecurityprocedurestheBangladeshBankofferstoverifytheauthenticityofthe
sourceofanitembyfollowingtheproceduresoutlinedintheBangladeshBankParticipating
BankModulespecifications.
9.3.2.AllBEFTNfilesoriginatedbythesendingbankwillbedigitallysignedandencryptedby
the presenting bank before transmission to BEFTN and all outgoing BEFTN files will be
digitallysignedandencryptedbyBEFTNbeforebeingtransmittedtothereceivingbank.
9.3.3.Eachsendingbankandreceivingbankshallpreventanydisclosureofanyaspectsof
thesecurityproceduresofferedbytheBangladeshBank,asprovidedinBangladeshBanks
ParticipatingBankModulespecifications.Thesendingbankorthereceivingbankshallnotify
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.

31


SECTION9.4SendingBanksAgreements
BysendinganitemtotheBangladeshBank,thesendingbank:
(a)

agrees to comply with the applicable BEFTN rules and agrees that those rules govern the
relationshipsamongthesendingbank,thereceivingbankandotherpartiesinterestedinthe
itemandcoveredbythoserules;

(b)

authorizestheBangladeshBanktoprocesstheiteminaccordancewiththeseRules.

(c)

agreesthattheBangladeshBankprocessestheitemsastheBEFTNoperatoranddoesnot
collect,present,orreturntheitemsasacollectingorreturningbank.,

(d)

authorizestheBangladeshBankholdingthesendingbankssettlementaccounttodebitthe
amount of a credit item, or credit the amount of a debit item, to the sending banks
settlementaccountonthesettlementdate;and

(e)

agreestoindemnifytheBangladeshBankprocessingorsettlingfortheitemforanylossor
expense (including attorneys fees and expenses of litigation) incurred by the Bangladesh
BankasaresultofanyactiontakenwithrespecttotheitembytheBangladeshBank.

SECTION9.5ProcessingofItems
9.5.1.TheBangladeshBankprocessesitemsinaccordancewiththeapplicableBEFTNrules.
TheBangladeshBankmayreject,ormayimposeconditionstoitsprocessingof,anyitemfor
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,theBangladeshBankwillnotprocessthefilewithoutapprovalbythesendingbank
oritsagent.ExceptasexpresslyprovidedintheseRulestheBangladeshBankdoesnothave
or assume any responsibility for a sending or receiving banks compliance with applicable
BEFTNrules.TheBangladeshBankmayrecordbyaudiorecordingdeviceanytelephonecall
relatingtoanitem.
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
containedinthefiles.Thesendingbankisresponsibleforverifyingtheinformationinthe
acknowledgment and notifying the Bangladesh Bank immediately of any discrepancy, and
fornotifyingtheBangladeshBankpromptlyofnonreceiptofanacknowledgment.
9.5.3.Asendingbankmustdesignatethereceivingbankforanitembyroutingnumber.The
BangladeshBankisnotresponsiblefortheaccuracyofaroutingnumbercontainedinand/or
verballysuppliedfromapublication,listorautomatedfileissuedbyanorganizationother
thanBangladeshBank.TheBangladeshBankmayprocessanitemonthebasisofarouting
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.

32

SECTION9.6DeliveryofItems
9.6.1. By prior arrangement with a receiving bank, the Bangladesh Bank sends items by
electronicmeanstothereceivingbank,orwiththepriorapprovalofBangladeshBanktoa
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
andmadetheitemsavailableforthereceivingbankoritsagenttoretrieve.Inemergency
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,exceptasprovidedinparagraph9.6.2.Areceivingbankshouldpromptlyadvisethe
BangladeshBankifitdoesnotreceiveitemsbytheexpecteddate.
9.6.2.Areceivingbankmustmanageitselectronicconnectionsoastopermitittoreceive
itemsinatimelymannerthroughouttheday.Areceivingbankthatdoesnotreceiveitems
in a timely manner because it fails to so manage its electronic connection, or because of
emergencycircumstancesbeyondthecontroloftheBangladeshBank,isrequiredtosettle
for the items with the Bangladesh Bank on the settlement date, but is not considered to
receivetheitemsforpurposesofthedeadlineforreturn.
9.6.3.Areceivingbankmaydesignateareceivingpointasitsagenttoreceiveitemsfromthe
BangladeshBank.Itisthereceivingbanksresponsibilitytoensurethatitsagentcomplies
withthereceivingbanksobligationsundertheseRules
(a)

ByreceivingitemsfromtheBangladeshBankatareceivingpointthatisownedor
operated by an entity other than the receiving bank itself, a receiving bank
designatestheentitythatoperatesthereceivingpointasitsagentforaccessingthe
BEFTN items., authorizes the Bangladesh Bank to act on the instructions of such
agentwithrespecttothehandlingofitemsreceivedfromtheBangladeshBankby
theagentonbehalfofthereceivingbank.

(b)

The receiving banks agents access to the Bangladesh Banks electronic systems is
governed by the Bangladesh Bank Participating Bank Module specifications, as
amendedfromtimetotime

(c)

ThereceivingbankauthorizestheBangladeshBanktoactuponitems,information,
andinstructionssenttotheBangladeshBankbythereceivingbanksagentthatthe
agentidentifiesashavingbeenauthorizedbythereceivingbank.

(d)

Thereceivingbankagreesthat:
(i)

its agent will be granted credentials authorizing such agent to access the
BangladeshBanksystemsforthepurposesoftheBEFTNservice;

(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 Banks
BEFTNsystemsonbehalfofotherbanksthatusethesameagenttoaccess
the Bangladesh Banks electronic systems. It is the responsibility of the
receiving bank and its agent to establish controls sufficient to assure that
theagentproperlysegregatestheitems,information,andinstructionsofa
receiving bank from any items, information, or instructions of other
receivingbanks.TheBangladeshBankisnotrequiredtotake,andwillnot
take, any measures to assure that the receiving banks work is properly
identifiedorsegregatedbytheagent.

33


(e)

Thereceivingbankagreestobeboundbytheagentsactsoromissionswithrespect
toitemsthatarehandledbytheBangladeshBankpursuanttotheseRules.

(f)

The receiving bank authorizes the Bangladesh Bank to settle for items sent to or
received from the Bangladesh Bank by the receiving banks 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
receivedfromtheBangladeshBankbythereceivingbanksagent.

(g)

ThereceivingbankagreesthattheBangladeshBankmaysenditemstothereceiving
bankbydeliveringortransmittingsuchitemstothereceivingbanksagent.

(h)

The Bangladesh Bank may rely on the agency appointment until it is revoked in
writingandtheBangladeshBankhashadareasonableamountoftimetorespondto
suchrevocation.

(i)

Thereceivingbankisresponsibleforanyobligationsregardingsettlementofitems
thatexistatthetimeofanyterminationoftheagencyappointmentandtheseshall
survivetheterminationoftheagencyappointment.

(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
omissionsofthereceivingbanksagent;(ii)theBangladeshBanksactsoromissions
in carrying out the instructions of such agent within the scope of the agency
appointment;or(iii)theSubmemberaccessarrangementincludingbutnotlimited
to attorneys fees and expenses of litigation, except for any claim, loss, cost, or
expensearisingsolelyoutoftheBangladeshBanksfailuretoexerciseordinarycare
ortoactingoodfaith.

SECTION9.7TimeSchedules,SettlementDatesandExtensionofTimeLimits
9.7.1 The BEFTN items processing schedule as published from time to time will show the
bankingdaysandthedeadlinesfortheBangladeshBanktoreceivecreditanddebititemsof
various classes for immediate or next day settlement. The time schedule also shows the
effectivedatewindowforclassesofitemsandprovisionsforsettlementforvariouseffective
dates.
9.7.2TheBangladeshBankprocessesitemsinaccordancewith their processingschedules,
and sends them to the receiving bank on or before the settlement date. If, because of
circumstances beyond the Bangladesh Banks 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
circumstancesrequire.
SECTION9.8DesignationofSettlementAccount
9.8.1Priortosendinganitemto(orreceivinganitemfrom)theBangladeshBank,asending
bank (and a receiving bank) must designate a settlement account(s) on the Bangladesh
Banksbooks,andidentifythetransactionstobesettledthroughtheaccount(s).Ifthebank
designates a correspondent banks account, the correspondent bank must agree to that
designation.AsendingbankorreceivingbankremainsresponsibleundertheseRulesforall
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 banks obligation with

34

respecttoanitemfromthesendingorreceivingbank,respectively,withoutpriornoticeor
demand.
9.8.2 The Bangladesh Bank may charge against a sending banks or a receiving banks
designated settlement account the amount of the banks BEFTN transactions, unless the
Bangladesh Bank and the sending or receiving bank agree to other arrangements for
settlement.
9.8.3Bydesignatingasettlementaccount,abank(anditscorrespondentbank,ifany,that
maintainsthedesignatedsettlementaccount)authorizestheBangladeshBank;(1)todebit
thedesignatedaccountonthesettlementdatetheamountofcredititemssentbythebank
totheBangladeshBank,theamountofdebititemssenttothebankbytheBangladeshBank;
(2) to credit to the designated account on the settlement date the amount of debit items
sentbythebanktotheBangladeshBank,theamountofcredititemssenttothebankbythe
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
BEFTNItems.
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
withparagraph10oftheseRulesabalanceofactuallyandfinallycollectedfundssufficient
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,ifany,withrespecttoitscorrespondentaccountholder).
9.8.4 By designating a settlement account, and in consideration of the processing and
settlementbytheBangladeshBankofitemssenttoand/orreceivedbythebankandother
sending and receiving banks, the bank (and its correspondent bank, if any, that maintains
thedesignatedsettlementaccount)agreestotheapplicableBEFTNrules,asamendedfrom
timetotime,forthebenefitofallpartiesinterestedintheitems.
9.8.5Asettlementdesignationsupersedesallpriorinconsistentdesignationswithrespectto
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
designationbywrittennoticetothebank.
SECTION9.9Settlement
9.9.1AsendingorreceivingbankssettlementobligationisowedtotheBangladeshBank.
9.9.2 On the settlement date, the Bangladesh Bank debits (or credits) that account in the
amountofacredit(ordebit)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
sendingorreceivingbankusesforsettlement)totheBangladeshBank,thebankgrantsto
theBangladeshBankallthebanksright,title,andinterestinproperty,whethernowowned
or hereafter acquired, in the possession or control of, or maintained with, the Bangladesh
Bank including but not limited to the banks deposit account, items in the process of
collection and their proceeds, and any investment property (including securities, security
entitlements,andsecurityaccounts),butexcludinganyinvestmentpropertywhichthebank
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
amountowedtoitbythebank,includingbutnotlimitedtotheexerciseofsetoffwithout

35

demandornoticeandeveniftheobligationsarecontingentorunmatured,therealization
on any available collateral, and the exercise of any rights it may have as a creditor under
applicablelaw.
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
processingandrefusetosettleforanitemiftheyreceivenoticeofthesuspensionorclosing
ofthesendingbankorreceivingbankpriortothetimesettlementisfinalundertheseRules.
IftheBangladeshBankceasesprocessingorrefusestosettleforanitem,theywillnotifythe
sendingbankandareceivingbanktowhichtheitemhasbeensent(oracorrespondentbank
whoseaccountabankusesforsettlement)assoonaspossible.
SECTION9.10AvailabilityofCredit
9.10.1 Credit given for a debit item by the Bangladesh Bank is available for use and may
qualifyasreserveonthesettlementdate,subjecttoparagraph9.4,andotherprovisionsof
thisarticle. TheBangladeshBank mayrefusetopermit theuseofcredit givenforadebit
item if it judges that there may not be sufficient funds in the sending banks settlement
accounttocoverchargebackorreturnoftheitem.
9.10.2CreditgivenbytheBangladeshBankforacredititemisfinalandavailableforuseand
mayqualifyasreserve.
SECTION9.11ReceivingBanksAgreements
9.11.1 A receiving bank, by maintaining or using an account with the Bangladesh Bank for
settlementofitemsorbyacceptinganitemfromtheBangladeshBank:
(a)

agreestocomplywiththeapplicableBEFTNrulesandagreesthatthoserulesgovern
the relationships among the sending bank, the receiving bank and other parties
interestedintheitemandcoveredbythoserules;

(b)

agreestoprocesstheiteminaccordancewiththisArticle;

(c)

agreesthattheBangladeshBankprocessestheitemastheBEFTNoperatoranddoes
notcollect,present,orreturntheitemsascollectingorreturningbank;

(d)

authorizestheBangladeshBanktocredittheamountofacredititem,ordebitthe
amountofadebititemtothereceivingbankssettlementaccountonthesettlement
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
foregoingagreementsorofanyactiontakenbytheBangladeshBankinaccordance
withitsRules.

9.11.2 The agreements, authorization and indemnity in paragraph 9.11.1 do not limit any
otheragreement,authorizationorindemnitynotinconsistent withparagraph9.11.1made
byareceivingbanktoasendingbank,theBangladeshBankoranotherperson.

SECTION9.12RevocationofItems
9.12 1 A sending bank may not amend or revoke an item after it has been sent to the
BangladeshBank,exceptasprovidedinapplicableBEFTNrules.

36

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.NothingintheseRulesconstitutesawaiverbyanyBangladeshBankofarightof
recoveryundertheapplicablelawofmistakeandrestitution.
SECTION9.13ReturnofItemsandFunds
9.13.1 A receiving bank may return a debit or credit item to the Bangladesh Bank in
accordancewiththeapplicableBEFTNrulesandbythedeadlinesetforthintheBEFTNtime
schedule.Thereceivingbankisaccountablefortheamountofadebititemifthereturned
itemisnotreceivedbythatdeadline.
9.13.2TheBangladeshBankprocessesareturneditemitreceivesfromareceivingbankand
sendsitormakesitavailabletothesendingbankinaccordancewiththeprovisionsofthese
Rules governing the processing of items. On the settlement date, the Bangladesh Bank
debitsorcreditsthesettlementaccountofthereceivingbankintheamountofareturned
debitorcredititem,andcreditsordebitsthesettlementaccountofthesendingbankinthe
amountofthereturneddebitorcredititem
SECTION9.14DisputedReturns
Ifasendingbankdisputestheproprietyofareturneditemonetimeinaccordancewithapplicable
BEFTNrules,theBangladeshBankwillprovisionallysettleforthedisputedreturn,subjecttoreceipt
of funds from the receiving bank. If the receiving bank disputes the sending banks claim in
accordancewithapplicableBEFTNrules,theBangladeshBankwillreversetheprovisionalsettlement
forthedisputedreturn,subjecttoreceiptoffundsfromthesendingbank.
SECTION9.15AdvicesofCreditandDebit;ReportingofErrors
TheBangladeshBankprovidesadvicesofcreditanddebittoanaccountholderforitemsforwhich
the account holder has agreed to settle. An advice of credit indicates that credit has been given,
subjecttotheprovisionsoftheseRulesTheBangladeshBankalso,onrequest,providesadvicestoa
personotherthanthebankoritscorrespondent,asthebanksagent.
SECTION9.16Records
Eachsendingandreceivingbankmustkeeprecordsforsixyearsthatpermitittoresolvequestions
thatariseconcerningthehandlingofitems,andtoresenditemsiftheBangladeshBanknotifiesit
thattheitemshavebeenlostbecauseofacomputeroutageorotherreason.TheBangladeshBank
keepsrecordsofitemsprocessedfortwelveyearsafterthesettlementdate.
SECTION9.17Fees
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
penaltytoaParticipatingBankforviolatingtheRulesandotherinstructionstothisregard.
SECTION9.18NonValueMessages
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
BangladeshBanksliabilityfordamagecausedbyitsfailuretoexerciseordinarycareorbyitsownor
itsemployeeswilfulmisconduct,inprocessinganonvaluemessagemaynotexceedtheamountof
anyfeepaidtotheBangladeshBankforthemessage.

37

SECTION9.19BangladeshBankLiability
9.19.1LimitationofLiability
(a)

theBangladeshBankisresponsibleorliableonlytoasendingbank,andareceiving
bank only for its own failure to exercise ordinary care, or for its own or its
employeeswilfulmisconduct;

(b)

the Bangladesh Bank does not act as the agent or subagent of another bank or
personandisnotliablefortheinsolvency,neglect,misconduct,mistakeordefault
ofanotherbankorperson;

(c)

the Bangladesh Bank does not make any warranty with respect to an item it
processesorsettlesforundertheseRulesand

(d)

no banking company may make a claim against the Bangladesh Bank for loss
resultingfromtheBangladeshBanksprocessingoforsettlingforanitemafterone
yearfromthesettlementdateoftheitem.Ifabank(orcorrespondentbank,ifany)
doesnotsendwrittenobjectiontoanadviceofdebittotheBangladeshBankwithin
thirtycalendardaysafterreceiptoftheadvice,itisdeemedtoapprovethedebiton
itsownbehalf(andon behalfofasendingorreceivingbank usingtheaccountfor
settlement,ifany).

9.19.2ThemeasureofdamagesfortheBangladeshBanksfailuretoexerciseordinarycare,
orforitsownoritsemployeeswilfulmisconductisasfollows:
(a)

Foracredititem(includingareturnedcredititem),itsliabilityislimitedtodamages
thatareattributabledirectlyandimmediatelytothefailuretoexerciseordinarycare
ortothewilfulmisconduct,anddoesnotincludedamagesthatareattributableto
theconsequencesofsuchconduct,evenifsuchconsequenceswereforeseeableat
thetimeofsuchconduct.

(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
thatcouldnothavebeenrealizedbytheuseofordinarycare.Wherethereiswilful
misconduct with respect to a debit item, the measure of damages includes other
damagesthatareattributabledirectlyandimmediatelytothewilfulmisconduct,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.

SECTION9.20AsofAdjustments
TheBangladeshBank,initsdiscretion,maysatisfyitsobligationtopaycompensationintheformof
interestby:
(a)

providinganasofadjustmenttoasendingorreceivingbankinanamountequalto
theamountonwhichinterestistobecalculatedmultipliedbythenumberofdays
forwhichinterestistobecalculated;or

(b)

paying compensation in the form of interest to a sending bank, receiving bank or

anotherpartytotheitemthatisentitledtosuchpayment

SECTION9.21RighttoAmend
TheBangladeshBankreservestherighttoamendthisArticleatanytimewithoutpriornoticewith
theconsentoftheBangladeshBankBoard.

38

ARTICLETEN
DEFINITIONOFTERMS

SECTION10.1DefinitionsAsUsedInTheseRules
(1)

Alphanumericmeansanycharacter09,AZ,az,blank,andprintablespecialcharacters
which have an ASCII value greater than hexadecimal 1F. Fields defined in these Rules as
alphanumericmaycontainanyoftheseallowablecharacters.

(2)

ANSIASCX12.5(InterchangeControlStructure)meansthestandardtodefinethecontrol
structuresfortheelectronicinterchangeofbusinesstransactionsencodedinASCX12based
syntax. This standard provides the interchange envelope of a header and trailer for the
electronicinterchangethroughadatatransmission,astructuretoacknowledgethereceipt
andprocessingofthisenvelope,andoptional,interchangelevelservicerequeststructures.

(3)

ANSI ASC X12.6 (Application Control Structure) means the standard used to define the
structure of business transactions for computertocomputer interchange. This structure is
expressedusingasymbolicrepresentationofX12dataintermsofboththedesignanduse
ofX12structures,independentofthephysicalrepresentation(e.g.,charactersetencoding).

(4)

BEFTN means a funds transfer system operator governed by the Rules of the BEFTN
Membershipwhichprovidesfortheinterbankclearingofelectronicentriesforparticipating
Banks.

(5)

BPRorBPSDataSegmentorBeginningSegmentforPaymentOrder/RemittanceAdvice
means the beginning segment for the payment order/remittance advice used in ASC X12
basedsyntaxtoindicatethebeginningofapaymentrelatedtransactionsetwhichcontains
thenecessaryBankinginformationtoprocessthetransaction.

(6)

BankingDaymeans,withreferencetoaParticipatingBank,anydayonwhichsuchBankis
opentothepublicduringanypartofsuchdayforcarryingonsubstantiallyallofitsBanking
functions,and,withreferencetotheBEFTN,andanydayonwhichtheappropriatefacilityof
suchEFTOperatorisbeingoperated.

(7)

BusinessDaymeansacalendardayotherthanFriday,SaturdayorNationalholiday.

(8)

Corporate Debit or Credit means a credit or debit entry initiated by an organization to

consolidatefundsofthatorganizationfromitsbranches,franchisesoragents,orfromother
organizations, or to fund the accounts of its branches, franchises or agents, or of another
organization.

(9)

ConsumerDebitorCreditmeansacreditentryinitiatedbyoronbehalfoftheholderofa
ConsumerAccounttoaffectatransferoffundstotheaccountoftheReceiver.

(10)

Consumer Account means an account held by a Participating Bank and established by a

naturalpersonprimarilyforpersonal,familyorhouseholdandnotforcommercialpurposes.

(11)

ConsumerEntrymeans acreditordebitentryinitiated byan organization pursuant to a

standing or a single entry authorization from a Receiver to affect a transfer of funds to or
fromaConsumerAccountoftheReceiver.

(12)

Electronic means relating to technology having electrical, digital, magnetic, wireless,

optical,electromagnetic,orsimilarcapabilities.

39

(13)

ElectronicRecordmeansanagreement,authorization,writtenstatement,orotherrecord
created,generated,sent,communicated,received,orstoredbyelectronicmeans.

(14)

ElectronicSignaturemeansanelectronicsound,symbol,orprocessattachedtoorlogically
associated with an agreement, authorization, written statement, or other record and
executedoradoptedbyapersonwiththeintenttosigntherecord.

(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(acreditentry),(2)forthewithdrawalofmoneyfromthetransactionaccountor
generalledgeraccountofaReceiver(adebitentry),(3)azeroTakaentry.Forallentries
exceptrepresentedchequeentries,eachdebitentryshallbedeemedanitem.

(16)

Entry data means, as applicable, returned entries, adjustment entries, notifications of

changeand/orothernoticesordatatransmittedthroughtheBEFTNpursuanttotheseRules.

(17)

FilemeansagroupofentriescomplyingwiththerequirementsofAppendixTwo(BEFTN
Record Format Specifications), associated with a given transmittal register and the control
totalssetforththerein.

(18)

InboundentrymeansanentrythatoriginatesinanothercountryandistransmittedtoThe
People'sRepublicofBangladesh.

(19)

NonSettled entry means an entry for which settlement cannot be completed under the
rulesgoverningthesettlementofthatentry.

(20)

Organizationmeansacorporation,partnership,associationorotherentity,governmental
orprivate,oranaturalperson,providedthat,inthecaseofanaturalperson,anyaccountof
suchpersontobedebitedorcreditedwiththeamountofanyentryismaintainedprimarily
forcommercialandnotforpersonal,familyorhouseholdpurposes.

(21)

OriginatingBankingCompanyorOBmeansaoriginatingbankingcompanywithrespect
toentries (1)ittransmitsdirectlyorindirectlytotheBEFTNOperatorfortransmittaltoan
RB, and (2) on which it is designated as the OB in accordance with Appendix Two (BEFTN
RecordFormatSpecifications).

(22)

OriginatormeansapersonthathasauthorizedanOBtotransmit(1)acreditentrytothe
accountofaReceiverwithaRB,or,iftheReceiverisalsotheRB,tosuchReceiver,or(2)a
debitentrytotheReceiverstransactionaccountorgeneralledgeraccountwithaRB,or,if
theReceiverisalsotheRB,tosuchReceiver.

(23)

ParticipatingBankmeansaBankthat(1)isauthorizedbylawtoacceptdeposits,(2)has
beenassignedaroutingnumberbyBEFTNauthority(BangladeshBank),and(3)hasagreed
tobeboundbytheseRulesasineffectfromtimetotime.OnlyParticipatingBanksmayact
asOBsorRBs.

(24)

Personmeansanaturalpersonoranorganization.

(25)

PrivateSectorOperator:meansanentitythatexecutesanannualagreementwithBEFTN
inwhichtheentityagreestocomplywithorperformallofthefollowing:

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 Operators rules and to these Rules (except that the Bangladesh Bank shall
notberequiredtobindaParticipatingBanktoanyprovisionofsuchrulesofPrivate
SectorOperatorthatisnotincorporatedbytheserues;

40

provide clearing, delivery, and settlement services for Private Sector Operators
entries, as defined by these Rules, between Participating Banks that have selected
thePrivateSectorOperatortoperformEFTservices;

processandeditfilesbasedontherequirementsoftheseRules;

evaluate the credit worthiness of and apply risk control measures to their
ParticipatingBanks;

adhere to the Bangladesh Banks Policy Statement on Multilateral Settlement

Systems(asapplicable);and

adheretoanyBEFTNPerformanceStandardsastheyaredeveloped.

(26)

Recordmeansinformationthatisinscribedonatangiblemediumorthatisstoredinan
electronicorothermediumandisretrievableinperceivableform.

(27)

ReceivermeansapersonthathasauthorizedanOriginatortoinitiate(1)acreditentryto
theReceiversaccountwithaRB,or,iftheReceiverisalsotheRB,tosuchReceiver,or(2)a
debitentrytotheReceiverstransactionaccountorgeneralledgeraccountwithaRB,or,if
the Receiver is also the RB, to such Receiver. With respect to debit entries, the term
Receivershallbedeemedtomeanallpersonswhosesignaturesarerequiredtowithdraw
funds from an account for purposes of the warranty provisions of subsection 2.2.1
(Warranties).

(28)

ReceivingBankingCompanyorRBmeansaParticipatingBankthatisanRBwithrespect
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
(BEFTNRecordFormatSpecifications).

(29)

Send means to deposit in the mail or to communicate by any other usual means with
postageorcostoftransportationprovidedforandproperlyaddressed,orbyfacsimile.

(30)

SettlementDatemeansthedateanexchangeoffundswithrespecttoanentryisreflected
onthebooksoftheBangladeshBank.

(31)

Single Entrymeansaonetime transferoffundsinitiatedby anOriginatorinaccordance

with the Receivers authorization for a single BEFTN credit or debit to the Receivers
ConsumerAccount.

(32)

Transmitmeanstodeliverbyelectronicmeansofcommunication.

(33)

ZeroEntrymeansanentrywhichcarriesazeroamountbutdoesincludepaymentrelated
remittance data. Zero entries are limited to corporate entries that carry remittance data
related to the payment. For example, preadvice entries that carry remittance data that
indicatesacreditpositionoftheOriginatortotheReceiver,orentriesrelatingtoaperiodof
timeduringwhichnofundsareowedbytheOriginatortotheReceiver.

SECTION10.2ConstructionRules
Unless the context otherwise requires, words in a singular number include the plural, and in the
pluralincludethesingular.ThetermsectionreferstoasubdivisionofanArticlecontainingatwo
digit number (e.g., 2.1); the term subsection refers to a subdivision of a section containing a
threeorfourdigitnumber(e.g.,2.1.1).

41

SECTION10.3Otherdefinitions
(1)

Access:therightoforopportunityforaninstitutiontousetheEFTservicesofBEFTNsystem
tosettlepaymentsonitsownaccountorforcustomers.

(2)

Addenda record: an EFT record type that carries the supplemental data needed to
completelyidentifyanaccountholderorprovideinformationconcerningapaymenttothe
RBandthereceiver.

(3)

Automated Clearing House: the EFT Network is a multilateral electronic clearing system in
whichchequesandotherpaymentinstructionsarebeingexchangedamongScheduleBanks.
The system involves transmitting, reconciling and calculating the net position of each
individualparticipantattheendofatransactionperiod.

(4)

Automated teller machine: an electromechanical device that permits authorized users,

typicallyusingmachinereadableplasticcards,towithdrawcashfromtheiraccountand/or
accessotherservices,suchasbalanceenquiries,transferoffundsoracceptanceofdeposits.
ATMsmaybeoperatedeitheronlinewithrealtimeaccesstoanauthorizationdatabaseor
offline.

(5)

Bankingday:anydayonwhichaparticipatingbankisopentothepublicduringanypartof
thedayforcarryingonsubstantiallyallitsbankingfunction.

(6)

BankingSystem:allBanksthatinparticularacceptdeposits,provideand/orofferpayment
services directly to users as one of their core business functions. This includes the central
bankaswell.

(7)

Batch: the transmission of processing of a group of payment instructions and/or security

transferinstructionsasasetatdiscretetimeinterval.

(8)

Business continuity: a payment systems arrangements which aim to ensure that it meet
agreedservicelevelsevenifoneorcomponentsofthesystemfailsorifitisaffectedbyan
abnormalexternalevent.Includebothpreventivemeasuresandarrangementstodealwith
contingencies.

(9)

CentralDepositoryBangladeshLtd.(CDBL)afacilityforholdingthesecuritieswhichenables
securities transactions to be processed by book entry. Physical securities may be
immobilizedbythedepositoryorsecuritiesaredematerialized(i.e.sothattheyexistonlyas
electronicrecords).Inadditiontosafekeeping,CDBLorsomeotherorganizationlikeitmay
incorporatecomparisonandclearingfunctionaswell.

(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
thetermisused(imprecisely)toincludesettlement.

(11)

Collateral:anasset pledgedbyaborrowertosecurealoanorothercredit,andsubjectto
seizureintheeventofadefault,alsocalledsecurity.

(12)

Confirmation: a process whereby a market participant notifies its counterparties or

customersofthedetailsofatradeandtypicallyallowsthemtimetoaffirmortoquestion
thetrade.

(13)

Consumer account: a deposit account held by a bank and established by a natural person
primarilyforpersonal,familyorhouseholduseandnotforcommercialpurpose.

(14)

Correspondent banking: an arrangement under which one bank (correspondent) holds

depositsownedbyotherbanks(respondents)andprovidespaymentandotherservicesto

42

thoserespondentbanks.Sucharrangementsmayalsobeknownasagencyrelationshipsin
somedomesticcontext.
(15)

Counterparty:theoppositepartytoafinancialtransactionsuchasasecuritiestradeorswap
agreement.

(16)

Credit risk: the risk that a counterparty will not settle an obligation for full value, either
whendueoranytimethereafter.Inexchangeforvaluesystems,theriskisgenerallydefined
toincludereplacementcostriskandprinciplerisk.

(17)

CSE:ChittagongStockExchange.

(18)

Custody:thesafekeepingoffinancialdocumentsandinstruments

(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

representownershipofsecuritiessothatsecuritiesexistonlyasaccountingrecords.

(22)

Depository: an agent with the primary role of recording securities either physically or
electronicallyandkeepingrecordsoftheownershipofthesesecurities

(23)

Directdebit:amethodofcollectionusedinEFTforcertainclaims,generallythosethatare
repeatedoveraperiodoftime,underwhichthedebtorgiveshisorherbankauthorization
todebithisorheraccountuponthereceiptofanentryissuedbyacreditor.

(24)

DirectDeposit:anEFTservicethatprovidesfortheelectronictransferoffundsdirectlyinto
theaccountofapayee,usuallyanemployeereceivingsalaryorsocialsecuritybenefits.

(25)

DSE:DhakaStockExchange.

(26)

EffectiveEntryDate:thedatetheoriginatorexpectspaymenttotakeplace.TheBEFTNreads
theeffectiveentrydatetodeterminethesettlementdate.

(27)

Electronic Funds Transfer (EFT): a generic term used to describe any Electronic Funds
Transfer.

(28)

Entry:anelectronicitemrepresentingthetransferoffundsintheEFT.

(29)

Field:oneormoreconsecutive characterpositionswithinan EFTentrymappedtocontain

specific information. For credit, debit or ATM cards, a defined area within an information
trackofthemagneticstripeoffixedorvariablelength.

(30)

File:agroupofEFTbatchesinitiatedintotheEFTNetworkorsortedfordeliverytoEFTbyan
OB on behalf of a respondent bank. A file must be transmitted electronically via data
transmissioninbetweentheOBandtheBEFTN.Afilemaybedeliveredtoanendpointvia
direct data transmission, CD, or other magnetic media. A file may contain one or more
batchesofentries.

(31)

Funds Availability: the time at which the funds resulting from a funds transfer are made
availabletothecustomer.

(32)

End user: a customer of a bank to which the bank provides payment instruments and
servicestofacilitatethecompletionoftheirfinancialtransactions

(33)

Finality:irrevocableandunconditional

43

(34)

Gross settlement system: a transfer system in which the settlement of funds or securities
transferinstructionoccursindividually(onatransactionbytransactionbasis)

(35)

Immobilization:placementofphysicalcertificatesofsecuritiesandfinancialinstrumentsina
centraldepositorysothatsubsequenttransfercanbemadebybookentry

(36)

Institutional arrangements: a transfer and organizational arrangement to provide various

typesofpaymentservicesfrombankandotherorganizationtousers.Theyincludemarket
arrangements, the legal and regulatory framework, and mechanisms for consultation and
coordinationamongstakeholdersinthenationalpaymentsystem.

(37)

Interoperability:asituationinwhichpaymentinstrumentsbelongingtoagivenschememay
be used in systems installed by other schemes. Interoperability requires technical
compatibilitybetweensystems,butcanonlytakeeffectwherecommercialagreementshave
beenconcludedbetweentheschemesconcerned.

(38)

Intraday credit: credit extended for a period of less than one business day; in a credit
transfer system with endofday final settlement, intraday credit is obviously extended to
thereceivingbankifitacceptsandactsonapaymentordereventhoughitwillnotreceive
finalfundsuntiltheendofthebusinessday.Alsocalleddaylightoverdraft,daylightexposure
anddaylightcredit.

(39)

Intraday liquidity: funds which can be accessed during the business day, usually to enable
Bankstomakepaymentsinrealtime.

(40)

Largevaluepayments: a payment generally involving a very large amount, which is mainly

exchanged between banks or between participants in the financial markets and usually
requiresurgentandtimelysettlement.Theyareoftenrelatedtoimportantfinancialmarket
transactions such as money market of foreign exchange transactions as well as many
commercialtransactions.

(41)

Legal risk: the risk of loss because of the unexpected application of a law or regulation or
becauseacontractcannotbeenforced.

(42)

Liquidity risk: the risk that a counterparty (or participant in a settlement system) will not
settleanobligationforfullvaluewhendue.Liquidityriskdoesnotimplythatacounterparty
orparticipantisinsolventsinceitmaybeabletosettletherequireddebtobligationatsome
unspecifiedtimethereafter.

(43)

Loss sharing agreement: an agreement among participants in a clearing or settlement

systemregardingtheallocationofanylossesarisingfromthedefaultofaparticipantinthe
systemorofthesystemitself.

(44)

MagneticInkCharacterRecognition(MICR):aspecialtypeofinkwhichcreatesamachine
readableimage.ThisMICRcodelineisinputtedatthebottomofeverychequethatcomes
toaBangladeshElectronicChequeProcessingsystem.

(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
nationalbasisintheUSA.

(46)

National payment system: the institutional and infrastructure arrangements in a financial

systemforinitiatingandtransferringmonetaryclaimsintheformofcommercialbankand
centralbankliability.

(47)

Net settlement system: a settlement system in which final interbank settlement of

individualtransferinstructionsoccursonanetbasisatoneormorediscrete,specifiedtimes
duringaprocessingday.

44

(48)

Netting:anagreedoffsettingofpositionsorobligationsbytradingpartnersorparticipants.
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(suchasthoserelatedtooperatinghours,fees,sanctions,deliveryofitems,formats
etc.)

(50)

Novation:thereplacementofexistingobligationsbynewobligationsbetweentheexistingor
substitutepartiesthatsatisfactoryandlegallydischargetheoriginalobligation.

(51)

OnusEntry:entrywithinanEFTfiledestinedforanaccountholderattheOriginatingBank.

(52)

Operationalrisk:theriskthatdeficienciesininformationsystemsorinternalcontrolscould
resultinunexpectedlosses.

(53)

Oversight: a central bank function whereby the objectives of safety and efficiency in
paymentandsettlementsystemsarepromotedbymonitoringexistingandplannedsystems,
accessingthemagainsttheseobjectivesandwherenecessary,includingchange.

(54)

Payment: the payers transfer of a monetary claim on a party acceptable to the payee.
Typically,monetaryclaimstaketheformofbanknotesordepositbalancesheldataBanksor
atacentralbank.

(55)

Payment infrastructure: the entirety of network facilities, technologies and procedures for
accessing and transacting payment instruments and for processing, clearing and settling
relatedpayments.

(56)

Payment infrastructure services: services provided through the payment infrastructure for
accessing and transacting payment instruments and for processing, clearing and settling
relatedpayments.

(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.
Alsocalledpaymentinstructions.

(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
transfersystemthatensuresthecirculationofmoney.

(60)

Posting:theprocessofrecordingdebitsandcreditstoindividualaccountbalances.

(61)

Principal risk: the risk that the seller of a security delivers a security but does not receive
paymentorthatthebuyerofasecuritymakespaymentbutdoesnotreceivedelivery.Inthis
event,thefullprincipalvalueofthesecurityoffundstransferredisatrisk.

(62)

Realtime transfer: the transmission, processing and settlement of a funds or securities

transferinstructionsatthetimethatitisinitiated.

(63)

Retail payment: a payment between various consumers, businesses and governments of

relativelylowvalueandurgency.Itisapaymentwhichisnotcapturedinthedefinitionofa
largevaluepayment.

45

(64)

Retailpaymentinfrastructure:mechanismsusedfortransaction,clearingandsettlementof
relatively lowvalue nonurgent payments initiated through payment instruments such as
cheques,drafts,paymentorders,EFTcredittransfers,EFTdirectdebits,cardpaymentsetc.

(65)

Return:anyEFTentrythathasbeenreturnedtotheoriginatingbankbythereceivingbank
orbytheBEFTNbecauseitcannotbeprocessed.Thereasonsforeachreturnareincluded
withthereturnintheformofareturnreasoncode.

(66)

Reversal: any EFT entries or files sent within required deadlines to correct or reverse
previouslyoriginatederroneousentriesorfiles.

(67)

RoutingNumber:aninedigitnumberthatidentifiesaspecificbankbranch.Thesenumbers
areassignedbyBangladeshBank.

(68)

SECCodes:eachEFTtransactionisidentifiedandrecognizedbyathreedigitcodeknownas
the Standard Entry Class (SEC) Code, from which the type of payment and as well as the
consumer/corporateapplicationmightbeunderstood.

(69)

Securitiesinfrastructure:fullsetofarrangementsforthetrading,registrationandcustodyof
securitiesandfortheconfirmation,clearanceandsettlementofsecuritytransactions.

(70)

Security system: the institutional arrangements and infrastructure for issuing and
administering securities liabilities, administering and safekeeping holdings of securities
issues,andinitiating,confirming,matching,transferringandsettlingsecuritiestransactions.

(71)

Settlement:atransferoffundsbetweentwo(ormore)partiesincash,oronthebooksofa
scheduled bank, to complete one or more prior transactions, made subject to final
accounting.SettlementfortheEFTNetworkusuallyoccursthroughtheBangladeshBank.

(72)

Settlement Date: the date on which an exchange of funds with respect to an entry is
reflectedonthebooksoftheBBsaccount.

(73)

Settlement risk: general terms used to designate the risk that settlement in a transfer
systemwillnottakeplaceasexpected.Thisriskmaycomprisebothcreditriskandliquidity
risk.

(74)

Stakeholder: in a payment system stakeholders are those parties whose interests are
affectedbytheoperationofthesystem.

(75)

Straight through processing: the automated endtoend processing of trades/payment

transfers including the automated completion of confirmation, matching, generation,
clearingandsettlementorders.

(76)

Systemicrisk:theriskthatthefailureofoneparticipantinatransfersystem,orinfinancial
marketgenerally,tomeetitsrequiredobligationswillcauseotherparticipantsorBanksto
be unable to meet their obligations (including settlement obligations in a transfer system)
whendue.Suchafailuremaycausesignificantliquidityorcreditproblemsandasaresult,
mightthreatenthestabilityoffinancialmarkets.

(77)

SystemicallyImportantPaymentSystem(SIPS):apaymentsystemissystemicallyimportant
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
financialareamorewidely.

(78)

TransactionCode:thetwodigitcodeintheEFTrecordthatdetermineswhetheranentryisa
debitoracredittoasavingsaccount,generalledgeraccountorwhetheranentryisacredit
toaloanaccount.

46

THEAPPENDICES
TECHNICALSPECIFICATIONS
BEFTNPARTICIPATIONAGREEMENT

47

APPENDIXONE
BEFTNFILEEXCHANGESPECIFICATIONS
The following information outlines the requirements for processing electronic transmissions,
addressesthesequenceofrecordsinaBEFTNfile,andgivesadescriptiveoverviewofthevarious
logicalrecordscontainedinafile.
SECTION1.1ElectronicTransmissionRequirements
To ensure compatibility in electronic file transmission, necessary operating details (testing and
implementationplans)needtobeaddressedbetweenaParticipatingBankandBEFTN.
SECTION1.2BEFTNCD/DVDSpecifications
(Contingencyuseonly,subjecttoapprovalbytheBEFTN)
In contingency situations, data may be submitted on CD/DVD media, each record must be
terminatedbyCRLFcharactersequence.
SECTION1.3DataSpecifications
Allalphanumericandalphabeticfieldsmustbeleftjustifiedandspacefilled.Allnumericfieldsmust
berightjustified,unsigned,andzerofilled.CharactersusedinBEFTNrecordsarerestrictedto09,A
Z,az,space,andthosespecialcharactersanASCIIvaluegreaterthanhexadecimal1F.Occurrences
ofvaluesASCII001Farenotvalid.
SECTION1.4SequenceofRecordsinBEFTNFiles
Each file begins with a File Header Record. After the File Header may be any number of batches.
EachbatchisidentifiedbyaBatchHeaderRecordandcontains oneormoreEntryDetail Records.
ThenumberofaddendarecordsthataccompanyeachentryisdependentupontheStandardEntry
ClassCode.AttheendofeachbatchisaBatchControlRecord.EachfileisendedwithaFileControl
Record.
TherecordsinBEFTNfilesmustbeinthefollowingsequence:

FileHeaderRecord
Batch#1
Company/BatchHeaderRecord
EntryDetailRecordsorCorporateEntryDetailRecords
(with/withoutoptionalAddendaRecords)
Company/BatchControlRecord
Batch#2
Company/BatchHeaderRecord
EntryDetailRecordsorCorporateEntryDetailRecords
(with/withoutoptionalAddendaRecords)
Company/BatchControlRecord
Batch#n
Company/BatchHeaderRecord
EntryDetailRecordsorCorporateEntryDetailRecords
(with/withoutoptionalAddendaRecords)
Company/BatchControlRecord
FileControlRecord

48


Anyothersequencewillcausethefiletoberejected(seediagramsonthefollowingpages).
SECTION1.5FileStructure
FileHeaderRecord
TheFileHeaderRecorddesignatesphysicalfilecharacteristicsandidentifiestheimmediateorigin(
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
whichcanbeusedtoidentifythefileuniquely.
Company/BatchHeaderRecord
TheCompany/BatchHeaderRecordidentifiestheOriginatorandbrieflydescribesthepurposeofthe
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,routingofreturns,andothercontrolpurposes.Inaddition,theCompany/BatchHeader
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
EntryDetailRecordsinthebatch.
EntryDetailRecord,CorporateEntryDetailRecord
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
indicatedbytheTransactionCode.
TheinformationintheCompany/BatchHeaderRecordmustbeincorporatedwiththeEntryDetail
Records to describe fully that entry and all participants in the transaction. The information in the
Company/BatchHeaderRecordidentifiestheOriginator;theTraceNumberidentifiestheOB;BANK
accountinformationidentifiesboththeRBand the specificaccount.Inadditiontothe basicentry
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
appropriateTransactionCodesandzerosintheAmountfield.Zeroentriescanbebatchedwithother
entriesorbatchedseparately.AzeroentrymustbeaccompaniedbyatleastoneAddendaRecord.
ReturnentriesaredistinguishedbyspecialTransactionCodesandmustbebatchedseparatelyfrom
otherTakaentries.
AddendaRecord
AddendarecordswillbeusedbytheOriginatortosupplyadditionalinformationaboutEntryDetail
RecordsthatwillbepassedfromtheOBthroughtheBEFTNtotheRB.Addendarecordsassociated
withtheoriginalEntryDetailRecordorCorporateEntryDetailRecordwillnotbeincludedwithany
EntryDetailRecordbeingreturned.OnlyBEFTNsanctionedformatswillbepermitted,asspecified
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
correspondingnumberofaddendarecordsarelistedbelow:

APPLICATION
CONTENTS
MAXADDENDA
Mandatory/Optional
SeeAppendix2
CCD
1
Optional
SeeAppendix2
CIE
1
Optional
SeeAppendix2
NOC
1
Mandatory
SeeAppendix2
CTX
9,999
Optional
SeeAppendix2
PPD
1
Optional

49

APPLICATION
RETURNS
TRX

CONTENTS
SeeAppendix5
SeeAppendix2

MAXADDENDA
1
9,999

Mandatory/Optional
Mandatory
Mandatory

Company/Batch
Company/BatchControlRecord
TheCompany/BatchControlRecordcontainsthecounts,hashtotals,andtotalTakacontrols
fortheprecedingdetailentrieswithintheindicatedbatch.
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.
FileControlRecord
The File Control Record contains Taka, entry, and hash total accumulations from the
Company/BatchControlRecordsinthefile.Thisrecordalsocontainscountsofthenumber
ofblocksandthenumberofbatcheswithinthefile(orbatcheddatatransmittedtoasingle
destination).

SequenceofRecords:

One per file First logical record

File Header Record

Batch Header Record

One per batch

Entry Detail Record

Batch 1

Entry Detail Record

Batches 2-N

Batch Control Record

One per batch

Batch Header Record

Entry Detail Record
Batch N

Entry Detail Record

Batch Control Record

File Control Record

One per file, last

logical record

SECTION1.6TraceNumberSequenceinBEFTNFiles
BanksmustalwayspreparefilessothatindividualEntryDetailRecordswithinindividualbatchesare
in ascending Trace Number order (although Trace Numbers need not necessarily be consecutive).
TheTraceNumberinanAddendaRecordisthesameasthatoftheEntryDetailRecordwithwhich
theAddendaRecordisassociated.
AddendaRecordsmustbeinconsecutiveascendingorderbytheAddendaSequenceNumber.

50

APPENDIXTWO
BEFTNRECORDFORMATSPECIFICATIONS

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.
SECTION2.1BEFTNRecordFormats
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
transactionandconveyinformationrelatedtothedestinationandoriginofthetransactionaswellas
thetotalamountofdebitsandcreditswithinthefile.Theformatoftheserecordsisconsistentforall
entries,regardlessoftheStandardEntryClassCode.
Thesecondsetofrecordformats(2.1.2)containstheCompany/BatchHeaderandCompany/Batch
ControlRecords.TheBatchRecordsactasaninnerenvelopecombiningsimilarentriesandproviding
informationabouttheOriginator.LiketheFileRecords,theformatoftheserecordsisconsistentfor
allentries,regardlessoftheStandardEntryClassCode.TheremainingSequenceofRecords(2.1.3
2.1.23) contains the Entry Detail Records and Addenda Records according to Standard Entry Class
Code.
2.1.1BEFTNFileRecordFormatforAllEntries
AllEntriesFileHeaderRecord

FIELD

10

11

12

13

RECORD
TYPE
CODE

PRIORITY
CODE

IMMEDIATE
DESTINATION

IMMEDIATE
ORIGIN

FILE
CREATION
DATE

FILE
CREATION
TIME

FILEID
MODIFIER

RECORD
SIZE

BLOCKING
FACTOR

FORMAT
CODE

IMMEDIATE
DESTINATION
NAME

IMMEDIATE
ORIGIN
NAME

REFERENCE
CODE

Field
Inclusion
Requirement

Contents

1'

Numeric

bTTTTAAAAC

bTTTTAAAAC

YYMMDD

HHMM

UPPER
CASEAZ
NUMERIC
09

094'

10'

1'

Alphanumeric

Alphanumeric

Alphanumeric

Length

10

10

23

23

AllEntriesFileControlRecord

FIELD
DATAELEMENTNAME

1
RECORDTYPECODE

2
BATCHCOUNT

3
BLOCKCOUNT

4
ENTRY/ADDENDACOUNT

5
ENTRYHASH

6
TOTALDEBITENTRYTAKA
AMOUNTINFILE

7
TOTALCREDITENTRYTAKA
AMOUNTINFILE

8
RESERVED

FieldInclusion
Requirement

N/A

Contents

9'

Numeric

Numeric

Numeric

Numeric

$$$$$$$$$$

$$$$$$$$$$

Blank

Length

10

12

12

39

51

2.1.2BEFTNBatchRecordFormatforAllEntries
CompanyBatchHeader/Trailer(Control)Records
AllEntriesCompany/BatchHeaderRecord

FIELD

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
EDATE

EFFECTIVE
ENTRY
DATE

SETTLEMENT
DATE(JULIAN)

ORIGINATO
RSTATUS
CODE

BATCH
NUMBER

Field
Inclusion
Requirement

Insertedby
EFTOperator

ORIGINA
TING
BANK
IDENTIFI
CATION
M

Contents

5'

Numeric

Alphanumeric

Alphanumeric

Alphanumeric

Alphanume
ric

Alphanumeric

Alphanume
ric

YYMMDD

Numeric

Alphanume
ric

TTTTAAA
A

Numeric

Length

16

20

10

10

AllEntriesCompany/BatchControlRecord
FIELD

10

11

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

SERVICE
CLASS
CODE

ENTRY/
ADDENDA
COUNT

ENTRY
HASH

TOTALDEBIT
ENTRYTAKA
AMOUNT

TOTALCREDIT
ENTRYTAKA
AMOUNT

COMPANY
IDENTIFICATION

MESSAGE
AUTHENTICATION
CODE

RESERVED

ORIGINATING
BANK
IDENTIFICATION

BATCH
NUMBER

Field
Inclusion
Requirement

N/A

Contents

8'

Numeric

Numeric

Numeric

$$$$$$$$$$

$$$$$$$$$$

Alphanumeric

Alphanumeric

Blank

TTTTAAAA

Numeric

Length

10

15

15

10

19

2.1.3SequenceofRecordsforADVEntries
AdvFileHeaderRecord

FIELD

10

11

12

13

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

PRIORITY
CODE

IMMEDIATE
DESTINATION

IMMEDIATE
ORIGIN

FILE
CREATION
DATE

FILE
CREATION
TIME

FILEID
MODIFIER

RECORD
SIZE

BLOCKING
FACTOR

FORMAT
CODE

IMMEDIATE
DESTINATION
NAME

IMMEDIATE
ORIGIN
NAME

REFERENCE
CODE

Field
Inclusion
Requirement

Contents

1'

Numeric

bTTTTAAAAC

bTTTTAAAAC

YYMMDD

HHMM

UPPER
CASEAZ
NUMERIC
09

094'

10'

1'

Alphanumeric

Alphanumeric

Alphanumeric

Length

10

10

23

23

AdvFileControlRecord

FIELD

DATAELEMENT
NAME

RECORDTYPE
CODE

BATCH
COUNT

BLOCK
COUNT

ENTRY/ADDENDA
COUNT

ENTRY
HASH

TOTALDEBITENTRYTAKAAMOUNT
INFILE

TOTALCREDITENTRYTAKA
AMOUNTINFILE

RESERVED

FieldInclusion
Requirement

N/A

Contents

9'

Numeric

Numeric

Numeric

Numeric

$$$$$$$$$$$$$$$$$$

$$$$$$$$$$$$$$$$$$

Blank

Length

10

20

20

23

52

2.1.3SequenceofRecordsforADVEntries(continued)
AdvCompany/BatchControlRecord

FIELD

DATAELEMENT
NAME

RECORD
TYPECODE

SERVICE
CLASSCODE

ENTRY/
ADDENDA
COUNT

ENTRY
HASH

TOTALDEBITENTRYTAKA
AMOUNT

TOTALCREDITENTRY
TAKAAMOUNT

ACH
OPERATOR
DATA

ORIGINATINGBANK
IDENTIFICATION

BATCH
NUMBER

FieldInclusion
Requirement

Contents

8'

Numeric

Numeric

Numeric

$$$$$$$$$$$$$$$$$$

$$$$$$$$$$$$$$$$$$

Alphanumeric

TTTTAAAA

Numeric

Length

10

20

20

19

AdvEntryDetailRecord

FIELD

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
OFEFT
OPERATOR

SEQUENCE
NUMBER
WITHIN
BATCH

Field
Inclusion
Requirement

JULIAN
DATEON
WHICH
THIS
ADVICE
IS
CREATED
M

Contents

6'

Numeric

TTTTAAAA

Numeric

Alphanumeri
c

$$$$$$$$$$

Numeric

Alphanumeri
c

Alphanumeric

Alphanumeric

Alphanumeri
c

Numeric

TTTTAAAA

Numeric

Numeric

Length

15

12

22

2.1.4SequenceofRecordsforCCDEntries
CCDEntryDetailRecord

FIELD

10

11

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

IDENTIFICATION
NUMBER

RECEIVING
COMPANY
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field
Inclusion
Requirement

Contents

6'

Numeric

TTTTAAAA

Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Alphanumeric

Alphanumeric

Numeric

Numeric

Length

17

12

15

22

15

CCDAddendaRecord
FIELD

DATAELEMENTNAME

RECORDTYPECODE

ADDENDATYPECODE

PAYMENTRELATEDINFORMATION

ADDENDASEQUENCENUMBER

ENTRYDETAILSEQUENCENUMBER

FieldInclusionRequirement

Contents

7'

05'

Alphanumeric

Numeric

Numeric

Length

80

Position

0101

0203

0483

8487

8894

53

2.1.5SequenceofRecordsforCIEEntries

CIE Entry Detail Record

FIELD

10

11

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
NAME

INDIVIDUAL
IDENTIFICATION
NUMBER

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field
Inclusion
Requirement

Contents

6'

Numeric

TTTTAAAA

Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Alphanumeric

Alphanumeric

Numeric

Numeric

Length

17

12

15

22

15

CIE Addenda Record

FIELD

DATAELEMENTNAME

RECORDTYPECODE

ADDENDATYPECODE

PAYMENTRELATEDINFORMATION

ADDENDASEQUENCENUMBER

ENTRYDETAILSEQUENCENUMBER

FieldInclusionRequirement

Contents

7'

05'

Alphanumeric

Numeric

Numeric

Length

80

2.1.6SequenceofRecordsforCTXEntries

CTX CORPORATE ENTRY DETAIL RECORD

FIELD

DATA
ELEMENT
NAME

NUMBER
OF
ADDENDA
RECORDS

RECEIVING
COMPANY
NAME/ID
NUMBER

10

11

12

13

RESERVED

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

RECORD
TYPE
CODE

TRANSACTION
CODE

RECEIVING
BANK
IDENTIFICATION

CHECK
DIGIT

N/A

6'

Numeric

TTTTAAAA

Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

Numeric

Numeric

17

12

15

16

15

BANK
ACCOUNT
NUMBER

TOTAL
AMOUNT

IDENTIFICATION
NUMBER

Field
Inclusion
Requirement

Contents

Length

CTX ADDENDA RECORD

FIELD
DATA
ELEMENT
NAME
Field
Inclusion
Requirement

RECORD TYPE CODE

ADDENDA TYPE CODE

PAYMENT
RELATED
INFORMATION

ADDENDA
NUMBER

7'

05'

Alphanumeric

Numeric

Numeric

80

SEQUENCE

ENTRY
DETAIL
SEQUENCE NUMBER

Contents
Length

54

2.1.7SequenceofRecordsforPPDEntries
PPD Entry Detail Record
FIELD

10

11

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATION
NUMBER

INDIVIDUAL
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field
Inclusion
Requirement

Contents

6'

Numeric

TTTTAAAA

Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Alphanumeric

Alphanumeric

Numeric

Numeric

Length

17

12

15

22

15

PPD Addenda Record

FIELD

DATAELEMENTNAME

RECORDTYPECODE

ADDENDATYPECODE

PAYMENTRELATEDINFORMATION

ADDENDASEQUENCENUMBER

ENTRYDETAILSEQUENCENUMBER

FieldInclusionRequirement

Contents

7'

05'

Alphanumeric

Numeric

Numeric

Length

80

2.1.8SequenceofRecordsforTRXEntries
TRX Entry Detail Record
FIELD

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

ITEMTYPE
INDICATOR

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field
Inclusion
Requirement

N/A

Contents

6'

Numeric

TTTTAAAA

Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

Numeric

Numeric

Length

17

12

15

16

15

TRX Addenda Record

FIELD

DATAELEMENTNAME

RECORDTYPECODE

ADDENDATYPECODE

PAYMENTRELATEDINFORMATION

ADDENDASEQUENCENUMBER

ENTRYDETAILSEQUENCENUMBER

FieldInclusionRequirement

Contents

7'

05'

Alphanumeric

Numeric

Numeric

Length

80

SECTION2.2CodeValues

AddendaRecordIndicator
RecordFormatLocation:EntryDetailRecordandCorporateEntryDetailRecord
0Noaddendarecordfollowstheentry
55

1Oneormoreaddendarecordsfollowtheentry

AddendaTypeCodes
RecordFormatLocation:AddendaRecord
05AddendaRecord(AppliestoCCD,CIE,CTX,PPD,andTRXEntries)
98
Automated Notification of Change (NOC) Addenda Record and Automated Refused
NotificationofChange(NOC)AddendaRecord
99
Automated Return Entry Addenda Record, Automated Dishonoured Return Entry Addenda
RecordandAutomatedContestedDishonouredReturnEntryAddendaRecord

CheckDigitRoutineRequiredforBankRoutingNumber(ADV,CCD,CIE,CTX,PPD,TRX,dishonoured
returns,contesteddishonouredreturns,NOC,refusedNOC):
SubfieldwithBankingCompanyIdentificationMandatory.
TheCheckDigitiscomputedusingModulus10asfollows:
1.
MultiplyeachdigitintheRoutingNumberbyaweightingfactor.Theweightingfactorsfor
eachdigitare:
Position:12345678
Weights:57157157
2.
Addtheresultsoftheeightmultiplications.
3.
Subtractthesumfromthenexthighestmultipleof10.TheresultistheCheckDigit.

Example:
RoutingNo.
:07640125
Multiplyby
:57157157

Sum
:049620011035=121
CheckDigit
=9(130minus121)
OriginatorStatusCodes
RecordFormatLocation:Company/BatchHeaderRecord
0
FilepreparedbyBEFTN.
1
ThiscodeidentifiestheOriginatorasaBankwhichhasagreedtobeboundbytheseRules.
2
This code identifies the Originator as a government entity or agency not subject to these
Rules.

RecordTypeCodes
RecordFormatLocation:Thefirstpositionofallrecordformats.Thesecodesareuniquelyassigned
foreachtypeofrecordasfollows:
1FileHeaderRecordFormat
5Company/BatchHeaderRecordFormat
6EntryDetailRecordFormat(ConsumerandCorporate)
7AddendaRecordFormats
8Company/BatchControlRecordFormat
9FileControlRecordFormat

ServiceClassCodes
RecordFormatLocation:Company/BatchHeaderRecordandCompany/BatchControlRecord
200BEFTNEntriesMixedDebitsandCredits
220BEFTNCreditsOnly
225BEFTNDebitsOnly
280BEFTNAutomatedAccountingAdvices

56

StandardEntryClassCodes
RecordFormatLocation:Company/BatchHeaderRecord

TransactionCodes
RecordFormatLocation:EntryDetailRecord
CurrentCreditRecords(CurrentDepositAccounts)
21
AutomatedReturnorNotificationofChange
fororiginaltransactioncode22,23,or24
22
AutomatedDeposit
23
PrenotificationofDemandCreditAuthorization;
24
ZeroTakawithremittancedata(forCCDand
CTXentriesonly);

CurrentDebitRecords(CurrentDepositAccounts)
25Reserved
26AutomatedReturnorNotificationofChangefororiginaltransactioncode27,28,or29
27AutomatedPayment
29ZeroTakawithremittancedata(forCCDandCTXentriesonly)

SavingsAccountCreditRecords
30Reserved
31AutomatedReturnorNotificationofChangefororiginaltransactioncode32,33,or34
32AutomatedDeposit

SavingsAccountDebitRecords
35Reserved
36AutomatedReturnorNotificationofChangefororiginaltransactioncode37,38,or39
37AutomatedPayment

BankGeneralLedgerCreditRecords
41AutomatedReturnorNotificationofChangefororiginaltransactioncode42,43,or44
42AutomatedGeneralLedgerDeposit(Credit)

LoanAccountCreditRecords
51AutomatedReturnorNotificationofChangefororiginaltransactioncode52,53,or54
52AutomatedLoanAccountDeposit(Credit)

LoanAccountDebitRecords(forReversalsOnly)
55AutomatedLoanAccountDebit(ReversalsOnly)
56AutomatedReturnorNotificationofChangefororiginaltransactioncode55

AutomatedAccountingRecords(foruseinADVfilesonly)
ThesetransactioncodesrepresentaccountingentriesandnotactualBEFTNtransactions.
81CreditforBEFTNdebitsoriginated
82DebitforBEFTNcreditsoriginated
83CreditforBEFTNcreditsreceived
84DebitforBEFTNdebitsreceived
85CreditforBEFTNcreditsinrejectedbatches
86DebitforBEFTNdebitsinrejectedbatches
87SummarycreditforrespondentBEFTNactivity
88SummarydebitforrespondentBEFTNactivity

57

SECTION2.3GlossaryofFileFormatDataElements
FieldInclusionRequirements
ThefollowinginformationdefinestheneedforinclusionofcertaindatafieldsinBEFTNentries.This
involvesthestandardizationofthreedefinitions:Mandatory,Required,andOptional.

Mandatory for BEFTN Processing: A Mandatory field is necessary to ensure the proper routing
and/orpostingofaBEFTNentry.AnyMandatoryfieldnotincludedinaBEFTNrecordwillcause
thatentry,batch,orfiletoberejectedbytheBEFTN.ArejectedentrywillbereturnedtotheOBby
theBEFTN.ArejectedbatchorrejectedfilewillbereportedtotheOBorbytheBEFTN.

Required:TheomissionofaRequiredfieldwillnotcauseanentryreject attheBEFTN,butmay
causearejectattheRB.AnexampleistheBANKAccountNumberfieldintheEntryDetailRecord.If
thisfieldisomittedbyanOB,theRBmayreturntheentryasunabletobeposted.Dataclassifiedas
RequiredshouldbeincludedbytheOriginatorandOBtoavoidprocessingandcontrolproblemsat
theRB.

Optional:TheinclusionoromissionofanOptionaldatafieldisatthediscretionoftheOriginator
and OB. However, if a BANK does originate files using optional data fields, these fields must be
returnedtotheOBiftheentryisreturned.

GlossaryofDataElements
BEFTNData(ADV):35PositionsCompany/BatchControlRecordOptional;1PositionEntryDetail
RecordOptional
ThisfieldisusedasspecifiedbytheBEFTN.

58

APPENDIXTHREE
SPECIFICATIONSFORDATAACCEPTANCE

Thedataacceptancecriteriasetforthbelowappliestoentriessubmittedbys.Failuretomeetsuch
criteriawillresultintherejectionofanentirefile,batch,oranindividualentrybytheBEFTN.Amust
selecteitherthefilelevelrejectoptionorthebatchlevelrejectoptionandnotifytheBEFTNofits
choice.
SECTION3.1FileAcknowledgment
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),and3.6(AutomaticEntryDetailReturnEntry)ofthisAppendixThree.Ataminimum,the
acknowledgment includes information from the following fields within the File Header and File
ControlRecords:

ImmediateOrigin
ImmediateOriginName(ifavailable)

FileCreationDate

FileCreationTime(ifavailable)

FileIDModifier

FileEntry/AddendaCount

TotalDebitEntryAmountinFile

TotalCreditEntryAmountinFile

FileBatchCount

TheacknowledgmentalsocontainsthedateandtimethefilewasprocessedbytheBEFTNand,ifthe
filewasrejected,thereasonfortherejection.Ifthefilewasnotrejected,butoneormorebatches
wererejectedbytheBEFTN,theacknowledgmentwillalsocontainthefollowinginformationabout
eachrejectedbatch:

OriginatingBankIdentification
OriginatingBankName(ifavailable)

CompanyName

CompanyIdentification

BatchNumber

EffectiveEntryDate

BatchEntry/AddendaCount

TotalDebitAmount

TotalCreditAmount

ReasonforBatchRejection
SECTION3.2FileLevelRejectOption
If the bank chooses the file level reject option, any condition which would cause a batch to be
rejectedwillcausetheentirefiletoberejected.Automaticfilerejections,asdescribedinsection3.4
(AutomaticFileRejection)ofthisAppendixThree,arenotaffectedbythisoption.

59

SECTION3.3BatchLevelRejectOption
Ifthebankchoosesthebatchlevelrejectoption,anyconditionthatwouldcauseonlyabatchtobe
rejected will allow the BEFTN to accept the file but to reject the erroneous batch as described in
section3.5(AutomaticBatchRejection)ofthisAppendixThree.
SECTION3.4AutomaticFileRejections
Thefollowingerrorconditionswillalwayscausetheentirefiletoberejected:

Thefilecannotbesuccessfullyread,e.g.,datareadfailures,hardware/softwareerrorchecks
indicated.

Thefilecontainsanyundefinedrecordtype.

TheFileHeaderRecorddoesnotcontainthenumberofavalid(apointdefinedontheBEFTN
routingtablefile).

Thefileisoutofbalance,i.e.,oneormoreofthefollowingconditionsexist:

The summation of the counts, hash totals, and total amount on Company/Batch Control
RecordsdoesnotagreewiththeFileControlRecord.

TheactualnumberofblocksorbatchesinthefiledoesnotagreewiththeFileControlRecord
counts.

MandatoryfieldsintheFileHeaderRecordarenotvalid:

FileIDModifierisupperorlowercaseAZor09.

FormatCodeisnot1.

Thesequenceofrecordsinthefileisincorrect.

TheImmediateOrigin,FileCreationDate,FileCreationTime,andFileIDModifierareequalto
thatofapreviouslyacceptedfile.
SECTION3.5AutomaticBatchRejection
Thefollowingerrorconditionswillcausethebatchtoberejectedifbatchlevelrejectionhasbeen
specified,orwillcausetheentirefiletoberejectediffilelevelrejectionhasbeenspecified:

The batch contains invalid characters (i.e., characters not specified in Appendix One, BEFTN
FileExchangeSpecifications).

Except for files coming from another EFT Operator, the OB Identification in the
Company/BatchHeaderRecordisnottheroutingnumberofavalidOB.

TheServiceClassCodeinaCompany/BatchHeaderRecordisotherthanacurrentlyvalidcode.

TheTraceNumbersonthefilearenotinascendingsequencewithinabatch.

TheTransactionCodesinEntryDetailRecordsareinvalid.

TheAmountfieldinanEntryDetailRecordisnonnumeric.

Thesequenceofrecordsinthebatchisincorrect.

The batch is outofbalance, i.e., the counts, hash totals, or Takas in the Company/Batch
ControlRecordsdonotagreewiththesummationoftheentriesforthebatch.

TheCompanyNameisallspacesorallzeros.

TheCompanyEntryDescriptionisallspacesorallzeros.

TheCompanyIdentificationisallspacesorallzeros.

TheStandardEntryClassCodeintheCompany/BatchHeaderRecordisotherthanacurrently
validcode.

The Service Class Code in the Company/Batch Control Record is not the same as that in the
Company/BatchHeaderRecord.

ThefirsteightpositionsoftheTraceNumberinanEntryDetailRecordarenotthesameasthe
OB Routing Number in the corresponding (immediately preceding) Company/Batch Header
Record.

60

TheTransactionCodeinanEntryDetailRecordisnotvalidfortheServiceClassCodeinthe
Company/BatchHeaderRecord.EitheradebitTransactionCodeisinacreditbatch,oracredit
TransactionCodeisinadebitbatch.
TheTransactionCodeinanEntryDetailRecordisnotvalidfortheStandardEntryClassCodein
the Company/Batch Header Record. For Standard Entry Class Code NOC or RET, the
TransactionCodemustbe21,26,31,or36.
Returnandnonreturntransactionsareinthesamebatch.
Return, dishonoured return, and/or contested dishonoured return transactions are in the
samebatch.
TheBatchNumberintheCompany/BatchHeaderRecordisnonnumeric.
TheBatchNumberintheCompany/BatchControlRecordisnonnumeric.
TheBatchNumberintheCompany/BatchControlRecordisnotthesameastheBatchNumber
intheCompany/BatchHeaderRecord.

SECTION3.6AutomaticEntryDetailReturnEntry
BEFTNusesreturnreasoncodesforthefollowingerrorconditions.

(a)
RBNotQualifiedtoParticipate
(b)
ImproperEffectiveEntryDate
(c)
AmountFieldError
(d)
AddendaError
(e)
MandatoryFieldError
(f)
TraceNumberError
(g)
RoutingNumberCheckDigitError
(h)
NonSettlement
(i)
ReturnofImproperDebitEntry
(j)
ReturnofImproperCreditEntry

Theseerrorconditionswillnevercausetheentirefiletoberejectedbutwillalwayscausetheentry
detailrecordtobereturnedusinganAddendaRecordwithanAddendaTypeCodeof99:

Creationoftheresultingautomatedreturnentriesshallbeinaccordancewiththespecificationsin
AppendixFive(ReturnEntries).

61

APPENDIXFOUR
MINIMUMDESCRIPTIONSTANDARDS

TheserulesrequireeachRBtosendormakeavailabletoeachReceiverspecificminimumdescriptive
information concerning each credit or debit entry to the Receivers account. This descriptive
informationisasfollows:

(a) Postingdatetocustomersaccount
(b) Amountoftheentry
(c) Companyname
(d) Companyentrydescription
(e) Typeofaccount(e.g.,checking)
(f) Numberoftheaccount
(g) Amountofanychargesassessedagainsttheaccountforelectronicfundstransferservices
(h) Balancesinthecustomersaccountatthebeginningandatthecloseofthestatement
(i) AddressandtelephonenumbertobeusedforinquiriesornoticesoferrorsprecededbyDirect
InquiriesToorsimilarlanguage
(j) CompanyDescriptiveDate
(k) IndividualIdentificationNumber/IdentificationNumber

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

62

APPENDIXFIVE
RETURNENTRIES

ExceptasotherwiseprovidedinArticleFive,section5.1(ReturnofEntries)oftheseRules,aRBmay
return entries for any reason, provided it uses an appropriate Return Reason Code as specified in
thisAppendixand,ifitusesReturnReasonCodeR11orR17,provideditspecifiesthereasonforthe
return.IfnoappropriateReturnReasonCodeisspecifiedinthisAppendixFive,theRBshallusethe
codewhichmostcloselyapproximatesthereasonforreturn.
SECTION5.1AutomatedReturnEntries
NOTE: Throughout this section, banks will always be designated by their original names. For
example,theOBisthebankthatinitiallypreparedtheoriginalentry,andwhichwilleventuallyhave
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
deliveredorifitcontainsanerroneouscondition.

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 5153 of the Company Batch
Headerrecord.)TheSECcodeRETisusedbytheBEFTNonly.

TheAutomatedReturnEntryislookedatasanewentry,generatedbecausetheoriginalentryfailed
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,
andsoon.

TheFileCreationDateisofusetotheOBwhentheentryisbeingreturnedbytheBEFTN.Otherwise,
thisdataelementisforafilecreatedoutsidetheorganizationoftheOBandtheinformationisnot
helpful. The OB can determine if the date is from its own file by looking at Field 12 of the
Company/BatchHeaderRecord,whichnowcarriestheidentificationoftheinstitutionpreparingthe
returnentry.

There is nothing required in the format that limits the number of Entry Detail Record/Addenda
Recordpairstooneforeachbatch.Multipleentryreturnentrybatchescertainlymaybegenerated
fromoneoriginalbatch.
SECTION5.2NonAutomatedReturnEntries
IftheBEFTNagreestoacceptnonautomatedreturnentries,itmustconvertthemtotheautomated
formatatthepointofentryintothesystem.Areturnconvertedtotheautomatedformatmaybear
theStandardEntryClassRETwhentheoriginalStandardEntryClasscodeisnotavailable.
SECTION5.3AdjustmentEntries
IncompliancewithArticleSeven,section7.7(AdjustmentEntries)oftheRules,adjustmententries
areutilizedbyaRBwhen,uponreceivingnoticefromitsReceiverthatadebitentrywas,inwholeor
part,unauthorized,theRBcreditstheamountofsuchentrytoitsReceiversaccountandreturnsthe
erroneousentrytotheOB.

63

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
ReasonCodes(eitherR07orR9)designatedasapplicabletoadjustmententries.
SECTION5.4TableofReturnReasonCodes
CodesToBeUsedbytheRBforReturnEntries
R01
InsufficientFunds
The available and/or cash reserve balance is not sufficient to cover the amount of
thedebitentry.

R02
AccountClosed
ApreviouslyactiveaccounthasbeenclosedbyactionofthecustomerortheRB.

R03
NoAccount/UnabletoLocateAccount
The account number structure is valid and it passes the check digit validation, but
theaccountnumberdoesnotcorrespondtotheindividualidentifiedintheentry,or
theaccountnumberdesignatedisnotanopenaccount.(Note:ThisReturnReason
Code may not be used to return POP entries that do not contain an Individual
Name.)

R04
InvalidAccountNumber
The account number structure is not valid. The entry may fail the check digit
validationormaycontainanincorrectnumberofdigits.

R05
UnauthorizedDebittoConsumerAccountUsingCorporateSECCode
(Adjustmententries)
A CCD or CTX debit entry was transmitted to a Consumer Account of the Receiver
andwasnotauthorizedbytheReceiver.TheReceivermayrequestimmediatecredit
fromtheRBforanunauthorizeddebit.Therequestmustbemadeinwritingwithin
one hundred eighty calendar days after the RB sends or makes available to the
Receiverinformationpertainingtothatdebitentry.TheReceivermustalsoprovide
the RB with a written statement, pursuant to subsection 8.6.5 (Receivers Written
Statement),thatthedebitentrywasnotauthorizedbytheReceiver.Forpurposesof
thiscodeandrelatedOperatingRulesprovisions,adebitentry wasnotauthorized
byaReceiverif(1)theauthorizationrequirementsofArticleTwo,subsection2.1.2
(ReceiverAuthorizationandAgreement)havenotbeenmet;(2)thedebitentrywas
initiatedinanamountgreaterthanthatauthorizedbytheReceiver;or(3)thedebit
entry was initiated for settlement earlier than authorized by the Receiver. An
unauthorized debit entry does not include a debit entry initiated with fraudulent
intentbytheReceiveroranypersonactinginconcertwiththeReceiver.ARBusing
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
followingtheSettlementDateoftheoriginalentry.

R06
ReturnedperOBsRequest
TheOBhasrequestedthattheRBreturntheBEFTNentry.IftheRBagreestoreturn
the entry, the OB must indemnify the RB according to Article Five (Return,
Adjustment, Correction, and Acknowledgment of Entries and Entry Information) of
theseRules.

64

R07

R08

R09

R10

AuthorizationRevokedbyCustomer(adjustmententries)
TheRBscustomer(theReceiver)hasrevokedtheauthorizationpreviouslyprovided
to the Originator for this particular transaction. The Receiver may request
immediatecreditfromtheRBforanunauthorizeddebit.Therequestmustbemade
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
madeavailabletotheOBnolaterthantheopeningofbusinessontheBankingday
followingtheonehundredeightiethcalendardayfollowingtheSettlementDateof
the original entry. This code and related Operating Rule provisions apply to
Consumerentriesonly.

PaymentStopped
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, Recredit, and Adjustment) of
these Rules. The RB should verify the Receivers intent when a request for stop
paymentismadetoensurethisisnotintendedtobearevocationofauthorization
(R07).Astoppaymentordershallremainineffectuntiltheearliestofthefollowing
occurs:alapseofsixmonthsfromthedateofthestoppaymentorder,paymentof
the debit entry has been stopped, or the Receiver withdraws the stop payment
order.

UncollectedFunds
Sufficientbookorledgerbalanceexiststosatisfytheamountofthetransaction,but
the amount of transactions in the process of collection (i.e., uncollected checks)
bringstheavailableand/orcashreservebalancebelowtheTakavalueofthedebit
entry.

CustomerAdvisesNotAuthorized
ForentriestoConsumerAccountsthattheOriginatorofagiventransactionhasnot
been authorized to debit his account, the Receiver may request immediate credit
fromtheRBforanunauthorizeddebit.Therequestmustbemadeinwritingwithin
one hundred eighty calendar days after the RB sends or makes available to the
Receiverinformationpertainingtothatdebitentry.TheReceivermustalsoprovide
the RB with a written statement, pursuant to subsection 7.6.4 (Receivers Written
Statement),thatthedebitentrywasnotauthorizedbytheReceiver.Forpurposesof
thiscodeandrelatedOperatingRulesprovisions,adebitentry wasnotauthorized
bytheReceiverif(1)theauthorizationrequirementsofArticleTwo,subsection2.1.2
(ReceiverAuthorizationandAgreement)havenotbeenmet;(2)thedebitentrywas
initiatedinanamountgreaterthanthatauthorizedbytheReceiver;or(3)thedebit
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
mustreturntherescindedtransactiontotheBEFTNbyitsdepositdeadlineforthe
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
followingtheSettlementDateoftheoriginalentry.ThiscodeandrelatedOperating
RuleprovisionsapplytoConsumerentriesonly.

65

R11

R12

R14

R15

R16

R17

R20

R21

R22

R23

R24

Reserved
BranchSoldtoAnotherBank
ABankmaycontinuetoreceiveentriesdestinedforanaccountatabranchthathas
beensoldtoanotherBank.BecausetheRBnolongermaintainstheaccountandis
unabletoposttheentry,itshouldreturntheentrytotheOB.

RepresentativePayeeDeceasedorUnabletoContinueinthatCapacity
Therepresentativepayeeisapersonorinstitutionauthorizedtoacceptentrieson
behalfofoneormoreotherpersons, suchaslegallyincapacitatedadultsor minor
children.Therepresentativepayeeiseitherdeceasedorunabletocontinueinthat
capacity.Thebeneficiaryisnotdeceased.

BeneficiaryorAccountHolder(OtherthanaRepresentativePayee)Deceased
(1) The beneficiary is the person entitled to the benefits and is deceased. The
beneficiarymayormaynotbetheaccountholder;or
(2) Theaccountholder(actinginanonrepresentativepayeecapacity)isanowner
oftheaccountandisdeceased.

AccountFrozen
ThefundsintheaccountareunavailableduetospecificactiontakenbytheRBorby
legalaction.

FileRecordEditCriteria(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
identifiedintheaddendarecordinformationfieldofthereturn.

NonTransactionAccount
The BEFTN entry destined for a nontransaction account would include either an
accountagainstwhichtransactionsareprohibitedorlimited.

InvalidCompanyIdentification
TheidentificationnumberusedintheCompanyIdentificationFieldisnotvalid.This
ReturnReasonCodewillnormallybeusedonCIEtransactions.

InvalidIndividualIDNumber
TheReceiverhasindicatedtotheRBthatthenumberwithwhichtheOriginatorwas
identifiedisnotcorrect.

CreditEntryRefusedbyReceiver
The Receiver may return a credit entry because one of the following conditions
exists:(1)a minimumamountrequiredbytheReceiverhasnotbeenremitted;(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)theReceiverhasnotauthorizedthiscreditentrytothisaccount.

DuplicateEntry

66

The RB has received what appears to be a duplicate entry; i.e., the trace number,
date,Takaamountand/orotherdatamatchesanothertransaction.Thiscodeshould
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
handlethesituation.

R29
CorporateCustomerAdvisesNotAuthorized
TheRBhasbeennotifiedbytheReceiver(nonconsumer)thataspecifictransaction
hasnotbeenauthorizedbytheReceiver.

CodestobeUsedbytheOBforAutomatedDishonoredReturnEntries:

R61
MisroutedReturn
Thebankpreparingthereturnentry(theRBoftheoriginalentry)hasplacedthe
incorrectRoutingNumberintheRBIdentificationfieldincludingCheckDigit,ofthe
EntryDetailRecord).
R67
DuplicateReturn
TheOBhasreceivedmorethanonereturnforthesameentry.
R68
UntimelyReturn
Thereturnentryhasnotbeensentwithinthetimeframeestablishedbytheserules.
R69
FieldError(s)
OneormoreofthefollowingfieldsBankAccountNumber,OriginalEntryTrace
Number,Amount,IndividualIdentificationNumber/IdentificationNumber,
CompanyIdentification,and/orTransactionCodeareincorrect.TheOBmustinsert
theappropriatecode(s)fromthelistbelow,separatedbyanasterisk(*),withinthe
AddendaInformationFieldoftheAddendaRecordFormatforAutomated
DishonoredReturnstoindicatethefield(s)inwhichtheerrorsoccur:
01ReturnContainsIncorrectBankAccountNumber
02ReturnContainsIncorrectOriginalEntryTraceNumber
03ReturnContainsIncorrectDollarAmount
04ReturnContainsIncorrectIndividualIdentificationNumber/Identification
Number
05ReturnContainsIncorrectTransactionCode
06ReturnContainsIncorrectCompanyIdentificationNumber
07ReturnContainsanInvalidEffectiveEntryDate

R70
PermissibleReturnEntryNotAccepted/ReturnNotRequestedbyOB
TheOBhasreceivedareturnentryidentifiedbytheRBasbeingreturnedwiththe
permissionof,orattherequestof,theOB,buttheOBhasnotagreedtoacceptthe
entryorhasnotrequestedthereturnoftheentry.Thiscodemaybeusedonlyto
dishonorreturnentriescontainingreturnreasoncodesR06andR31.

CodestobeusedbytheRBforAutomatedContestedDishonoredReturnEntries:

R71
MisroutedDishonoredReturn
Thefinancialinstitutionpreparingthedishonoredreturnentry(theOBofthe
originalentry)hasplacedtheincorrectRoutingNumberintheRBIdentificationfield
includingCheckDigit,oftheEntryDetailRecord).
R72
UntimelyDishonoredReturn
Thedishonoredreturnentryhasnotbeensentwithinthedesignatedtimeframe.

67

R73

R74

R75

R76

TimelyOriginalReturn
TheRBiscertifyingthattheoriginalreturnentrywassentwithinthe
timeframedesignatedintheserules.
CorrectedReturn
TheRBiscorrectingapreviousreturnentrythatwasdishonoredusing
ReturnReasonCodeR69(d(FieldErrors)becauseitcontainedincompleteor
incorrectinformation.Correcteddatawillbeinitsdefinedpositioninthe
Company/BatchHeader,EntryDetailRecord,orAddendaRecord,asfollows:
OriginalEntryTraceisintheReturnAddendaRecord,
DollaramountisintheEntryDetailRecord;
IndividualIdentificationNumber/IdentificationNumberisintheEntry
DetailRecord,forCCD,CTX,PPD;
CompanyIdentificationisintheCompany/BatchHeaderRecord
TransactionCodeisintheEntryDetailRecord
BankAccountNumberisintheEntryDetailRecord
OriginalReturnNotaDuplicate
Theoriginalreturnentrywasnotaduplicateofanentrypreviouslyreturned
bytheRB.ThiscodemaybeusedbytheRBtocontestanentrydishonored
bytheOBusingReturnReasonCodeR67(DuplicateReturn).
NoErrorsFound
TheoriginalreturnentrydidnotcontaintheerrorsindicatedbytheOBin
theDishonoredReturnEntrybearingReturnReasonCodeR69(FieldErrors).

BEFTNOperatorReturns
R13 RBNotQualifiedtoParticipate
R18 ImproperEffectiveEntryDate
R19 AmountFieldError
R25 AddendaError
R26 MandatoryFieldError
R27 TraceNumberError
R28 RoutingNumberCheckDigitError
R30 RBNotParticipantinCheckTruncationProgram
R32 RBNonSettlement
R34 ReturnofImproperDebitEntry
R35 ReturnofImproperCreditEntry
SECTION5.5RecordFormatsforAutomatedandConvertedReturnEntries
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
(BEFTNRecordFormatSpecifications)fortheFileHeader,Company/BatchControlandFileControl
Recordformats.]
5.5.1CorporateEntryDetailRecordFormatforReturns
ReturnsCorporateEntryDetailRecord

FIELD

DATA
RECORD TRANSACTION RECEIVINGBANK
ELEMENT
TYPE
CODE
IDENTIFICATION
NAME
CODE

10

11

12

13

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

TOTAL
AMOUNT

IDENTIFICATION
NUMBER

NUMBEROF
ADDENDA
RECORDS

RECEIVING
COMPANY
NAME/ID
NUMBER

RESERVED

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field

Inclusion
Requirement

N/A

Contents

1
Numeric

2
TTTTAAAA

3
Numeric

Alphanumeric

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

4
Numeric

68

Length

17

12

15

16

15

NOTE:ForReturnEntries,eachfieldoftheCorporateEntryDetailRecordremainsunchangedfrom
theoriginalentry,unlessotherwisenoted.
1.
Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under
currentlyassignedCodeValuesinAppendixTwo).
2.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheReturnEntry(i.e.,theOBof
theoriginalentry).
3.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumbercontainedinpositions0411.
4.
ChangedtotheTraceNumberassignedbytheinstitution.

5.5.2EntryDetailRecordFormatforReturns

ReturnsEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD TRANSACTION RECEIVINGBANK

TYPE
CODE
IDENTIFICATION/
CODE

10

11

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATIONNUMBER/
IDENTIFICATIONNUMBER/
CHECKSERIALNUMBER

INDIVIDUALNAME/
RECEIVINGCOMPANY
NAME

DISCRETIONARYDATA/
CARDTRANSACTION
TYPECODE

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

Field

Inclusion
Requirement

R/M

Contents

1
Numeric

2
TTTTAAAA

3
Numeric

Alphanumeric

4
$$$$$$$$

5
Alphanumeric

5
Alphanumeric

6
Alphanumeric

7
Numeric

Length

17

12

15

22

15

NOTE:ForReturnEntries,eachfieldoftheEntryDetailRecordremainsunchangedfromtheoriginal
entry,unlessotherwisenoted.
1.
Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under
currentlyassignedCodeValuesinAppendixTwo.)
2.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheReturnEntry(i.e.,theOBof
theoriginalentry).
3.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumbercontainedinpositions0411.
4.
ForCIEentries,positions4054areusedfora15characterIndividualName,andpositions
5576areusedfora22characterIndividualIdentificationNumber.
5.
ChangedtotheTraceNumberassignedbytheinstitutionpreparingtheAutomatedReturn
Entry.

5.5.4AddendaRecordFormatforReturns

ReturnsAddendaRecord

FIELD

DATA
ELEMENT
NAME

RECORDTYPE
CODE

ADDENDATYPE
CODE

RETURNREASON
CODE

ORIGINALENTRY
TRACENUMBER

DATEOFDEATH

ORIGINALRECEIVINGBANKIDENTIFICATION

ADDENDAINFORMATION

TRACENUMBER

Field

Inclusion
Requirement

Contents

99

Alphanumeric

1
Numeric

2
YYMMDD

3
TTTTAAAA

Alphanumeric

Numeric

69

Length

1.
2.
3.

15

44

15

Copydatafrompositions8094oftheEntryDetailRecord
TobeusedonlywithReturnCodeR14orR15.
Copydatafrompositions0411oftheoriginalEntryDetailRecord.

SECTION5.6DishonouredReturnEntriesbyBEFTN

ThefollowingspecificationsapplytoDishonouredReturnEntries:

Each Dishonoured Return Entry initiated by an OB must be in the automated format and
sequencesetforthinthisAppendixFive.
Terms used in the format shall have the meanings set forth in Appendix Two (BEFTN Record
FormatSpecifications).
The initiation of an Automated Dishonoured Return Entry with Return Reason Code R68
constitutesacertificationbytheOBthatthereturnwasuntimelyandalosswassuffered.
The Company/Batch Header Record, Entry Detail Record, and Addenda Record format as set
forthinthisAppendixFivemustbeused.
TheTransactionCodeusedintheEntryDetailRecordmustbe21or26forDemandAccounts,31
or36forSavingsAccounts,41or46forGeneralLedgerAccounts,or51or56forLoanAccounts.
AddendaTypeCode99mustbeusedtoindicatethattheaddendarecordcontainsautomated
returninformation.
The following fields of the Addenda Record must be filled when originating an Automated
DishonouredReturnEntry:
Positions3953containingtheReturnTraceNumber
Positions5456containingtheReturnSettlementDate
Positions5758containingtheReturnReasonCode
5.6.1Company/BatchHeaderRecordFormatforAutomatedDishonouredReturns

DishonouredReturnsCompany/BatchHeaderRecord

FIELD

DATA
RECORD SERVICE
ELEMENT
TYPE
CLASS
NAME
CODE
CODE
Field

Inclusion
Requirement

Contents

Length

COMPANY
NAME

Numeric Alphanumeric
3

16

COMPANY
COMPANY
DISCRETIONARY IDENTIFICATION
DATA

10

11

STANDARD
ENTRY
CLASS
CODE

COMPANYENTRY
DESCRIPTION

COMPANY
DESCRIPTIVE
DATE

EFFECTIVE
ENTRY
DATE

SETTLEMENT
DATE
(JULIAN)

ORIGINATOR
STATUS
CODE

12

13

ORIGINATING
BATCH
BANK
NUMBER
IDENTIFICATION

Insertedby
EFTOperator

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

YYMMDD

Numeric

1
Alphanumeric

2
TTTTAAAA

3
Numeric

20

10

10

NOTE: For Dishonoured Return Entries, each field of the Company/Batch Header Record remains
unchangedfromtheReturnEntry,unlessotherwisenoted.

1.
Changed to reflect the Originator Status Code of the institution initiating the Dishonoured
ReturnEntry(i.e.,theRBoftheReturnEntry).
2.
ChangedtoreflecttheRoutingNumberoftheinstitutioninitiatingtheDishonouredReturn
Entry(i.e.,theRBoftheReturnEntry).
3.
Changed toaBatchNumberassignedbytheinstitutionpreparingtheDishonouredReturn
Entry.

70

5.6.2CorporateEntryDetailRecordforAutomatedDishonouredReturns

DishonouredReturnsCorporateEntryDetailRecord

FIELD

DATA
RECORD
ELEMENT
TYPE
NAME
CODE

10

11

12

13

TRANSACTION
CODE

RECEIVINGBANK
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

N/A

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

3
Numeric

12

15

16

15

Field

Inclusion
Requirement

Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE: For Dishonoured Return Entries, each field of the Corporate Entry Detail Record remains
unchangedfromtheReturnentry,unlessotherwisenoted.

1.
Changed to the Routing Number of the institution receiving the Dishonoured Return Entry
(i.e.,theOBoftheReturnEntry).
2.
Changed to the Check Digit calculated according to BEFTN Standards and based on the
RoutingNumbercontainedinpositions0411.
3.
ChangedtotheTraceNumberassignedbytheinstitutionpreparingtheDishonouredReturn
Entry(i.e.,theRBoftheReturnEntry).

5.6.3EntryDetailRecordFormatforAutomatedDishonouredReturns

DishonouredReturnsEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

10

11

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION/
OGOIDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATIONNUMBER/
IDENTIFICATIONNUMBER/
CHECKSERIALNUMBER

INDIVIDUALNAME/
RECEIVINGCOMPANY
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

$$$$$$$$

Alphanumeric

3
Alphanumeric

Alphanumeric

4
Numeric

12

15

22

15

Field

Inclusion
Requirement

Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE: For Dishonoured Return Entries, each field of the Entry Detail Record remains unchanged
fromtheReturnEntry,unlessotherwisenoted.

1.
Changed to the Routing Number of the institution receiving the Dishonoured Return Entry
(i.e.,theOBoftheReturnEntry).
2.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumbercontainedinpositions0411.
3.
ChangedtotheTraceNumberassignedbytheinstitutionpreparingtheDishonouredReturn
Entry(i.e.,theRBoftheReturnEntry).

71

5.6.5AddendaRecordFormatforAutomatedDishonouredReturns

DishonouredReturnsAddendaRecord

FIELD
DATA
ELEMENT
NAME

RECORD
TYPE
CODE

Field

Inclusion
Requirement

ADDENDATYPE
CODE

DISHONOREDRETURN
REASONCODE

ORIGINAL
ENTRYTRACE
NUMBER
RESERVED

ORIGINAL
RETURNTRACE
RECEIVINGBANK
IDENTIFICATION RESERVED
NUMBER

N/A

N/A

10

11

12

RETURN
SETTLEMENT
DATE

RETURN
REASON
CODE

ADDENDA
INFORMATION

TRACE
NUMBER

99

Alphanumeric

1
Numeric

Blank

2
TTTTAAAA

Blank

Numeric

Numeric

Alphanumeric

Blank
3
[Alphanumeric]

15

15

21

Contents

Length

1.
2.
3.

4
Numeric

15

Copydatafrompositions721oftheAddendaRecordofthereturnentry.
Copydatafrompositions2835oftheAddendaRecordofthereturnentry.
TheAddendaInformationFieldofaDishonouredReturnEntryisamandatoryfieldwhenthe
Dishonoured Return bears Return Reason Code R69 (Field Errors). When using Return
ReasonCodeR69,theOBmustinserttheappropriatecode(s)fromthelistbelow,separated
byanasterisk(*),withintheAddendaInformationFieldoftheAddendaRecordFormatfor
AutomatedDishonouredReturnstoindicatethefield(s)inwhichtheerrorsoccur:

01
ReturnContainsIncorrectAccountNumber
02
ReturnContainsIncorrectOriginalEntryTraceNumber
03
ReturnContainsIncorrectTakaAmount
04
ReturnContainsIncorrectIndividualIdentificationNumber/IdentificationNumber
05
ReturnContainsIncorrectTransactionCode
06
ReturnContainsIncorrectCompanyIdentificationNumber
07
ReturnContainsanInvalidEffectiveEntryDate

4.

Forexample:01*03*06

For Automated Dishonoured Returns, changed to reflect the new Trace Number found in
positionsoftheEntryDetailRecordorCorporateEntryDetailRecord.

SECTION5.7ContestedDishonouredBEFTNReturnEntries
5.7.1AutomatedContestedDishonouredReturnEntries
EachAutomatedContestedDishonouredReturnEntryinitiatedbyaRBmustbeintheformatand
sequencesetforthinthisAppendixFive.

Terms used in the format shall have the meanings set forth in Appendix Two (BEFTN Record
FormatSpecifications).
The initiation of an Automated Contested Dishonoured Return Entry constitutes a certification
bytheRBthattheentrywasreturnedinaccordancewiththeseRules.
The Company/Batch Header Record, Entry Detail Record, and Addenda Record format as set
forthinthisAppendixFivemustbeused.

72

The Transaction Code used in the Entry Detail Record must be either 21 or 26 for Demand
Accounts,31or36forSavingsAccountsor51or56forLoanAccounts.
AddendaTypeCode99mustbeusedtoindicatethattheaddendarecordcontainsautomated
returninformation.
The following fields of the Addenda Record must be filled when originating an Automated
ContestedDishonouredReturnEntry:
DateOriginalEntryReturned
OriginalSettlementDate(JulianDate)
ReturnTraceNumber
ReturnSettlementDate
ReturnReasonCode
DishonouredReturntracenumber
DishonouredReturnSettlementDate
DishonouredReturnReasonCode

5.7.2NonAutomatedContestedDishonouredReturnEntries
AnEFTOperatorthatagreestoacceptnonautomatedContestedDishonouredReturnEntriesmust
convertthemtoanautomatedformatatthepointofentryintothesystem.
5.7.3CorrectedReturnEntries
A RB may generate a Corrected Return by creating a Contested Dishonoured Return with reason
codeR74.TheformatisthesameasthatforotherContestedDishonouredReturns.Thecorrected
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
EntryTraceNumber).
5.7.4Company/BatchHeaderRecordFormatforAutomatedContestedDishonoured
Returns

ContestedDishonouredReturnCompany/BatchHeaderRecord

FIELD

DATA
RECORD SERVICE
ELEMENT
TYPE
CLASS
NAME
CODE
CODE
Field

Inclusion
Requirement

Contents

Length

COMPANY
NAME
M

Numeric Alphanumeric
3

16

COMPANY
COMPANY
DISCRETIONARY IDENTIFICATION
DATA

STANDARD COMPANYENTRY
ENTRY
DESCRIPTION
CLASSCODE

10

11

COMPANY
DESCRIPTIVE
DATE

EFFECTIVE
ENTRY
DATE

SETTLEMENT
DATE
(JULIAN)

ORIGINATOR
STATUS
CODE

12

13

ORIGINATING
BATCH
BANK
NUMBER
IDENTIFICATION

Insertedby
EFTOperator

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

YYMMDD

Numeric

1
Alphanumeric

2
TTTTAAAA

3
Numeric

20

10

10

NOTE:ForContestedDishonouredReturnEntries,eachfieldoftheCompany/BatchHeaderRecord
remainsunchangedfromtheDishonouredReturnEntry,unlessotherwisenoted.

1.
Changed to reflect the Originator Status Code of the institution initiating the Contested
DishonouredReturnEntry(i.e.,theRBoftheDishonouredReturnEntry).
2.
Changed to reflect the Routing Number of the institution initiating the Contested
DishonouredReturnEntry(i.e.,theRBoftheDishonouredReturnEntry).
3.
Changed to a Batch Number assigned by the institution preparing the Contested
DishonouredReturnEntry.

73

5.7.5CorporateEntryDetailRecordFormatforAutomatedContestedDishonoured
Returns

ContestedDishonouredReturnsCorporateEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

10

11

12

13

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

TOTAL
AMOUNT

IDENTIFICATION
NUMBER

NUMBEROF
ADDENDA
RECORDS

RECEIVING
COMPANY
NAME/ID
NUMBER

RESERVED

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

N/A

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

3
Numeric

12

15

16

15

Field

Inclusion
Requirement

Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE: For Contested Dishonoured Return Entries, each field of the Corporate Entry Detail Record
remainsunchangedfromtheDishonouredReturnentry,unlessotherwisenoted.

1.
Changed to the Routing Number of the institution receiving the Contested Dishonoured
ReturnEntry(i.e.,theOBoftheDishonouredReturnEntry).
2.
Changed to the Check Digit calculated according to BEFTN Standards and based on the
RoutingNumber.
3.
Changed to the Trace Number assigned by the institution preparing the Contested
DishonouredReturnEntry(i.e.,theRBoftheDishonouredReturnEntry).

5.7.6EntryDetailRecordFormatforAutomatedContestedDishonouredReturns

ContestedDishonouredReturnsEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

10

11

TRANSACTION
CODE

RECEIVINGBANK
IDENTIFICATION/
OGOIDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATIONNUMBER/
IDENTIFICATIONNUMBER/
CHECKSERIALNUMBER

INDIVIDUALNAME/
RECEIVINGCOMPANY
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

$$$$$$$$

Alphanumeric

3
Alphanumeric

Alphanumeric

4
Numeric

12

15

22

15

Field

Inclusion
Requirement

Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE: For Contested Dishonoured Return Entries, each field of the Entry Detail Record remains
unchangedfromtheDishonouredReturnEntry,unlessotherwisenoted.

1.
Changed to the Routing Number of the institution receiving the Contested Dishonoured
ReturnEntry(i.e.,theOBoftheDishonouredReturnEntry).
2.
Changed to the Check Digit calculated according to BEFTN Standards and based on the
RoutingNumber.

74

3.

Changed to the Trace Number assigned by the institution preparing the Contested
DishonouredReturnEntry(i.e.,theRBoftheDishonouredReturnEntry).

5.7.7AddendaRecordFormatforAutomatedContestedDishonouredReturns

ContestedDishonouredReturnsAddendaRecord

FIELD

DATA
RECORD ADDENDA CONTESTED ORIGINAL
DATE
ORIGINAL
ORIGINAL RETURN
RETURN
ELEMENT
TYPE
TYPE DISHONORED ENTRY ORIGINAL RECEIVINGBANK SETTLEMENT TRACE SETTLEMENT
NAME
CODE
CODE
RETURN
TRACE
ENTRY
IDENTIFICATION
DATE
NUMBER
DATE
REASON
NUMBER RETURNED
(JULIAN)
CODE

10

RETURN
REASON
CODE

11

12

13

14

15

DISHONORED DISHONORED DISHONORED RESERVED TRACE

RETURN
RETURN
RETURN
NUMBER
TRACE
SETTLEMENT
REASON
NUMBER
DATE
CODE

Field

Inclusion
Requirement

N/A

Contents

99

Alphanumeric

1
Numeric

2
YYMMDD

3
TTTTAAAA

2
Numeric

Numeric

Numeric

Alphanumeric

Numeric

Numeric

Alphanumeric

Blank

4
Numeric

15

15

15

15

Length

1.
2.
3.
4.

Copy data from Original Entry Trace Number of the Addenda Record of the Dishonoured
ReturnEntry.
MandatoryonlyifContestedDishonouredReturnReasonCodeisR73.
CopydatafrompositionsOriginalReceivingBankoftheAddendaRecordoftheDishonoured
ReturnEntry.
For Automated Contested Dishonoured Returns, changed to reflect the new Trace Number
foundintheEntryDetailRecordorCorporateEntryDetailRecord.

75

APPENDIXSIX
NOTIFICATIONOFCHANGE

A Notification of Change is created by a RB to notify the OB that previously valid information

containedinapostedentryhasbecomeoutdatedorthatinformationcontainedinaprenotification
iserroneousandshouldbechanged.

ANotificationofChangeisinapplicabletoSharedNetworkTransactionswhentheRBisalsothecard
issuer.
SECTION6.1AutomatedNotificationofChange
AnAutomatedNotificationofChangemustcomplywiththefollowingspecifications:

Azeroamountmustbeindicated.
AddendaTypeCode98mustbeusedtoindicatethattheAddendaRecordcontainsautomated
changeinformation.
Field3oftheAddendaRecordmustcontaintheappropriatecodeindicatingtheinformationto
bechanged,inaccordancewiththeTableofChangeCodessetforthinthisAppendixSix.Field7
oftheAddendaRecordmustcontainthechange(correction)informationcorrespondingtothe
changecodeused,inaccordancewiththeTableofChangeCodessetforthinthisAppendixSix.
The Standard Entry Class Code COR must be used to denote a batch containing automated
changeinformation.
Company/BatchHeaderRecord,EntryDetailRecord,andAddendaRecordformatsassetforthin
thissectionmustbeused.
TheTransactionCode,EntryDetailRecordmustbeeither21,26,31,36,41,46,51,or56.
SECTION6.2NonAutomatedNotificationofChange
AnEFTOperatorthatagreestoacceptnonautomatedNotificationofChangeentriesmustconvert
themtotheautomatedformatatthepointofentryintothesystem.
SECTION6.3RefusedBEFTNNotificationofChange
ARefusedBEFTNNotificationofChangeiscreatedbyanOBtorefuseaNotificationofChangeentry
containing incorrect or incomplete information. The Refused Notification of Change must be in
automatedform.

EachautomatedRefusedNotificationofChangeentryofanOBmustbeintheformatandsequence
set forth in this Appendix Six and must contain the reason(s) for the refusal of the Notification of
ChangeEntry.
SECTION6.4MinimumDescriptionStandardsforNotificationsofChangeandCorrected
NotificationsofChange
AnOBmust,ataminimum,providetoeachofitsOriginatorsthefollowinginformation,withrespect
toeachNotificationofChangeorCorrectedNotificationofChangeentryreceivedbytheOB,within
twoBankingdaysoftheSettlementDateoftheNOCorCorrectedNOCentry:

(a)
CompanyName;
(b)
CompanyIdentification;
(c)
CompanyEntryDescription;

76

(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)

EffectiveEntryDate;
BankAccountNumber;
IndividualName/ReceivingCompanyName;
IndividualIdentificationNumber/
IdentificationNumber;
ChangeCode;
OriginalEntryTraceNumber;
OriginalReceivingBankIdentification;and
CorrectedData.

SECTION6.5TableofChangeCodes

TableofChangeCodes

Code
Meaning

C01
IncorrectBankAccountNumber
Correct BANK Account Number appears in first (left justification) 17 positions of the
CorrectedDataField.

Example:ThiscodewouldalsobeusedwhenanAccountNumberisincorrectlyformatted.

C02
IncorrectRoutingNumber
Correct Routing Number (including Check Digit) appears in first nine positions of the
CorrectedDataField.

Example:Duetomergerorconsolidation,aoncevalidRoutingNumbermustbechanged.

C03
IncorrectRoutingNumberandIncorrectBankAccountNumber
Correct Routing Number (including Check Digit) appears in first nine positions of the
Corrected Data Fieldcorrect BANK Account Number appears in the 13th through 29th
positionofsamefieldwithaspaceinthe9th,11th,and12thposition.

Example:Duetomergerorconsolidation,aoncevalidRoutingNumbermustbechanged,
andinmostinstancesthischangewillcauseachangetotheaccountnumberingstructure.

C04
IncorrectIndividualName/ReceivingCompanyName
Correct Individual Name/Receiving Company Name appears in first 22 positions of the
CorrectedDataField.

C05
IncorrectTransactionCode
CorrectTransactionCodeappearsinfirsttwopositionsoftheCorrectedDataField.

Example: An item which the RB determines should be posted to their Demand Deposit
Account(DDA)SystemcontainsaSavingsTransactionCode.

C06
IncorrectBankAccountNumberandIncorrectTransactionCode
Correct BANK Account Number appears in the first (left justification) 17 positions of the
CorrectedDataFieldcorrectTransactionCodeappearsinthe21stand22ndpositionsof
thesamefieldwithspacesinthe18th,19th,and20thpositions.

77

C07

C08
C09

C13

Example: An entry posting to a savings account should actually be going to a demand

accountorviceversa,andtheaccountnumberisalsoincorrect.

Incorrect Routing Number, Incorrect Bank Account Number, and Incorrect Transaction
Code
CorrectRoutingNumber(includingCheckDigit)appearsinthefirstninepositionsofthe
Corrected Data Fieldcorrect BANK Account Number appears in the 9th through 26th
positions of the same fieldand correct Transaction Code appears in the 27th and 28th
positionsofthesamefield.

Example: An entry posting to a savings account should actually be going to a demand

accountorviceversa,andtheroutingnumberandaccountnumberarealsoincorrect.

Reserved

IncorrectIndividualIdentificationNumber
Correctnumberappearsinfirst22positionsoftheCorrectedDataField.

Example: Individuals Identification Number within the Company is incorrect, either on

initialinputorthroughmergerorconsolidation.

AddendaFormatError
InformationintheEntryDetailRecordwascorrectandtheentrywasabletobeprocessed
andpostedbytheRB.However,informationfoundintheAddendaRecordwasunclearor
wasformattedincorrectly.

Example:ACorporateentryisreceivedwithan05AddendaTypeCode,buttheaddenda
informationdoesnotcontainpaymentrelatedANSIASCX12datasegmentsorendorsed
Bankingconventions.

TableofChangeCodesforRefusedNotificationofChangeEntries

ChangecodesC61C69areonlytobeusedwhenrefusingaNotificationofChange:

C61MisroutedNotificationofChange
C62IncorrectTraceNumber
C63IncorrectCompanyIdentificationNumber
C64IncorrectIndividualIdentificationNumber/IdentificationNumber
C65IncorrectlyFormattedCorrectedData
C66IncorrectDiscretionaryData
C67RoutingNumberNotFromOriginalEntryDetailRecord
C68BankAccountNumberNotFromOriginalEntryDetailRecord
C69IncorrectTransactionCode

TheRefused Notification ofChangeprocesscanonlybeusedwiththeaboveReasonCodes(C61

C69).Ifareasonotherthanthoselisted(C61C69)exists,theitemshouldbehandledoutsideofthe
RefusedNotificationofChangeprocess.(ThislimitationappliesonlytotheRefusedNotificationof
Changeprocess.)

78

SECTION6.6RecordFormatsforAutomatedandConvertedNotificationsofChange
Unless otherwise noted in the following record formats, the field contents for automated and
convertednotificationsof changeentrieswillmatchthefieldcontentsoftheoriginalentries.(See
Appendix Two (BEFTN Record Format Specifications) for the File Header, Company/Batch Control
andFileControlRecordformats.)
6.6.1Company/BatchHeaderRecordFormatforNotificationsofChange

NotificationofChangeCompany/BatchHeaderRecord

FIELD

DATA
RECORD SERVICE
ELEMENT
TYPE
CLASS
NAME
CODE
CODE
Field

Inclusion
Requirement

Contents

Length

COMPANY
NAME

COMPANY
COMPANY
DISCRETIONARY IDENTIFICATION
DATA

Alphanumeric
Numeric
3

10

11

STANDARD
ENTRY
CLASS
CODE

COMPANYENTRY
DESCRIPTION

COMPANY
DESCRIPTIVE
DATE

EFFECTIVE
ENTRY
DATE

SETTLEMENT
DATE
(JULIAN)

ORIGINATOR
STATUS
CODE

12

13

ORIGINATING
BATCH
BANK
NUMBER
IDENTIFICATION

Insertedby
EFTOperator

Alphanumeric

Alphanumeric

1
Alphanumeric

2
Alphanumeric

Alphanumeric

YYMMDD

Numeric

3
Alphanumeric

4
TTTTAAAA

5
Numeric

20

10

10

16

NOTE:ForNotificationofChangeEntries,eachfieldoftheCompany/BatchHeaderRecordremains
unchangedfromtheoriginalentry,unlessotherwisenoted.

1.
ContainsCORforallNotificationofChangeEntries.
2.
MaycontaintheidentificationoftheEFTOperator(BEFTN)convertingtheentry.
3.
ChangedtoreflecttheOriginatorStatusCodeoftheinstitutioninitiatingtheNotificationof
ChangeEntry(i.e.,theRBoftheoriginalentry).
4.
Changed to reflect the Routing Number of the institution initiating the Notification of
ChangeEntry.
5.
Changed to the batch number assigned by the institution preparing the Automated
NotificationofChangeEntry.
6.6.2CorporateEntryDetailRecordFormatforNotificationsofChange

NotificationofChangeCorporateEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

10

11

12

13

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

N/A

N/A

4
0000000000

Alphanumeric

Blank

Alphanumeric

Blank

Alphanumeric

5
Numeric

12

15

16

15

Field

Inclusion
Requirement

Contents

1
Numeric

2
TTTTAAAA

Length

3
Alphanumeric
Numeric
1

17

NOTE: For Notification of Change Entries, each field of the Corporate Entry Detail Record remains
unchangedfromtheoriginalentry,unlessotherwisenoted.

1.
Changed to the appropriate Transaction Code. (See Transaction Codes under currently
assignedCodeValuesinAppendixTwo.)
2.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheNotificationofChangeEntry
(i.e.,theOBoftheoriginalentry).
79

3.

Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumbercontainedinpositions0411.
Thisfieldmustbezerofilled.
Changed to the Trace Number assigned by the institution preparing the Automated
NotificationofChangeEntry.

4.
5.

6.6.3EntryDetailRecordFormatforNotificationsofChange

NotificationofChangeEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

10

11

TRANSACTION
CODE

RB
IDENTIFICATION

CHECK
DIGIT

Bank
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATION
NUMBER/
IDENTIFICATIONNUMBER

INDIVIDUALNAME/
RECEIVINGCOMPANY
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

4
0000000000

5
Alphanumeric

5
Alphanumeric

Alphanumeric

6
Numeric

12

15

22

15

RECORD
TYPE
CODE

Field

Inclusion
Requirement
Contents

1
Numeric

2
TTTTAAAA

Length

3
Alphanumeric
Numeric
1

17

NOTE:ForNotificationofChangeEntries,eachfieldoftheEntryDetailRecordremainsunchanged
fromtheoriginalentry,unlessotherwisenoted.

1.
ChangedtotheappropriateNotificationofChangeEntryTransactionCode.(SeeTransaction
CodesundercurrentlyassignedCodeValuesinAppendixTwo.)
2.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheNotificationofChangeEntry
(i.e.,theOBoftheoriginalentry).
3.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumber.
4.
Thisfieldmustbezerofilled.
5.
ForCIEentries,15charactersareusedforIndividualName,and22charactersareusedfor
IndividualIdentificationNumber.
6.
Changed to the Trace Number assigned by the institution preparing the Automated
NotificationofChangeEntry.
6.6.4AddendaRecordFormatforNotificationsofChange

NotificationofChangeAddendaRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

ADDENDA
TYPE
CODE

CHANGE
CODE

ORIGINALENTRY
TRACENUMBER

RESERVED

ORIGINALRECEIVING
BANKIDENTIFICATION

CORRECTED
DATA

RESERVED

TRACE
NUMBER

Field
Inclusion
Requirement

N/A

N/A

Contents

98

Alphanumeric

1
Numeric

Blank

2
TTTTAAAA

Alphanumeric

Blank

Numeric

Length

15

29

15

15

1.
2.

CopyTraceNumberfromtheEntryDetailRecordorCorporateEntryDetailRecord.
CopyRBRoutingNumberoftheoriginalEntryDetailRecord.

80

6.6.5Company/BatchHeaderRecordFormatforAutomatedRefusedNotificationsof
Change

RefusedNotificationofChangeCompany/BatchHeaderRecord

FIELD

DATA
RECORD SERVICE
ELEMENT
TYPE
CLASS
NAME
CODE
CODE
Field

Inclusion
Requirement

Contents

Length

COMPANY
NAME

COMPANY
COMPANY
DISCRETIONARY IDENTIFICATION
DATA

Numeric Alphanumeric
3

10

11

STANDARD
ENTRY
CLASS
CODE

COMPANYENTRY
DESCRIPTION

COMPANY
DESCRIPTIVE
DATE

EFFECTIVE
ENTRY
DATE

SETTLEMENT
DATE
(JULIAN)

ORIGINATOR
STATUS
CODE

12

13

ORIGINATING
BATCH
BANK
NUMBER
IDENTIFICATION

Insertedby
EFTOperator

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

Alphanumeric

YYMMDD

Numeric

1
Alphanumeric

2
TTTTAAAA

3
Numeric

20

10

10

16

NOTE: For Refused NOC Entries, each field of the Company/Batch Header Record remains
unchangedfromtheNOCentry,unlessotherwisenoted.
1.
ChangedtoreflecttheOriginatorStatusCodeoftheinstitutioninitiatingtheRefusedNOC
Entry(i.e.,theRBoftheNOCEntry).
2.
Changed to reflect the Routing Number of the institution initiating the Refused NOC Entry
(i.e.,theRBoftheNOCEntry).
3.
ChangedtotheBatchNumberassignedbytheinstitutionpreparingtheRefusedNOCEntry.
6.6.6 Corporate Entry Detail Record Format for Automated Refused Notifications of
Change

RefusedNotificationofChangeCorporateEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

10

11

12

13

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

N/A

$$$$$$$$

Alphanumeric

Numeric

Alphanumeric

Blank

Alphanumeric

3
Numeric

12

15

16

15

Field

Inclusion
Requirement

Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE:ForRefusedNOCEntries,eachfieldoftheCorporateEntryDetailRecordremainsunchanged
fromtheNOCentry,unlessotherwisenoted.

1.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheRefusedNOCEntry(i.e.,the
OBoftheNOCEntry).
2.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumber.
3.
ChangedtotheTraceNumberassignedbytheinstitutionpreparingtheRefusedNOCEntry
(i.e.,theRBoftheNOCentry).

81

6.6.7EntryDetailRecordFormatforAutomatedRefusedNotificationsofChange

RefusedNotificationofChangeEntryDetailRecord

FIELD

DATA
ELEMENT
NAME

10

11

TRANSACTION
CODE

RB
IDENTIFICATION/
OGOIDENTIFICATION

CHECK
DIGIT

BANK
ACCOUNT
NUMBER

AMOUNT

INDIVIDUAL
IDENTIFICATION
NUMBER/
IDENTIFICATIONNUMBER

INDIVIDUALNAME/
RECEIVINGCOMPANY
NAME

DISCRETIONARY
DATA

ADDENDA
RECORD
INDICATOR

TRACE
NUMBER

$$$$$$$$

Alphanumeric

Alphanumeric

Alphanumeric

3
Numeric

12

15

22

15

RECORD
TYPE
CODE

Field

Inclusion
Requirement
Contents

Numeric

1
TTTTAAAA

Length

2
Alphanumeric
Numeric
1

17

NOTE:ForRefusedNOCEntries,eachfieldoftheEntryDetailRecordremainsunchangedfromthe
originalentry,unlessotherwisenoted.

1.
ChangedtotheRoutingNumberoftheinstitutionreceivingtheRefusedNOCEntry(i.e.,the
OBoftheNOCEntry).
2.
Changed to the Check Digit calculated according to BEFTN standards and based on the
RoutingNumber.
3.
ChangedtotheTraceNumberassignedbytheinstitutionpreparingtheRefusedNOCEntry
(i.e.,theRBoftheNOCEntry).

6.6.8AddendaRecordFormatforAutomatedRefusedNotificationsofChange

RefusedNotificationofChangeAddendaRecord

FIELD

10

11

DATA
ELEMENT
NAME

RECORD
TYPE
CODE

ADDENDA
TYPE
CODE

REFUSED
CORCODE

ORIGINALENTRY
TRACENUMBER

RESERVED

ORIGINAL
RB
IDENTIFICATION

CORRECTED
DATA

CHANGE
CODE

CORTRACE
SEQUENCE
NUMBER

RESERVED

TRACE
NUMBER

N/A

N/A

Field

Inclusion
Requirement
Contents

98

Alphanumeric

1
Numeric

Blank

TTTTAAAA

Alphanumeric

2
Alphanumeric

Numeric

Blank

Numeric

Length

15

29

15

NOTE:ThisrecordformatshouldonlybeusedintherefusalofaNotificationofChangeEntry.
TheFile,Batch,andEntryDetailrecordformatsofanAutomatedRefusedNotificationofChangeare
thesameasanAutomatedNotificationofChangewiththeexceptionoftheAddendaRecord.

1.
Copy data from positions 0721 of the Addenda Record of the original Notification of
Change.
2.
Copy data from positions 0406 of the Addenda Record of the original Notification of
Change.

82

APPENDIXSEVEN
BEFTNPARTICIPANTAGREEMENT

(On Tk. 150 Non-Judicial Stamp)

BANGLADESHELECTRONICFUNDSTRANSFERNETWORK
PARTICIPANTAGREEMENTANDINDEMNITY

In consideration of the undersigned being admitted asa participating banking company ofthe
Bangladesh Electronic Funds Transfer Network ("BEFTN") acting as a facility to operate an
automatedclearinghouseoftheBangladeshBankprovidingsettlementandotherservices,andof
the mutual indemnification of the undersigned by each other participating banking company of
BEFTN:theundersigned,whichintendstoactasaparticipatingbankingcompanyofBEFTN,hereby
agreeswiththeBangladeshBank,andwitheachotherparticipatingbankingcompany:
1) to comply with and be subject to the BEFTN Operating Rules, (collectively referred to as the
"BEFTNRules")includingdescriptiverequirements,asineffectfromtimetotime;
2) tomakeallpaymentsrequiredbytheBEFTNRules;
3) 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,andamountspaidinsettlement(eachreferredtohereinas
a"cost")arisingfromanyfailureonthepartoftheundersignedtoexerciseordinarycareorto
complywithanyoftheprovisionsoftheBEFTNRules,exceptforamountspaidinsettlementof
such costs unless the undersigned shall have received 10 days' prior written notice of the
proposedsettlementthereof;
This agreement shall be governed by and construed in accordance with the laws the Peoples
Republic of Bangladesh. The undersigned and the Bangladesh Bank submit to the exclusive
jurisdictionofthecourtsofthePeoplesRepublicofBangladesh.
This agreement shall inure to the benefit of the Bangladesh Bank and shall be binding on the
undersignedanditssuccessorsandassigns,exceptnoParticipatingBankingCompanymaytransfer
orassignitsrightsorobligationshereunderexceptasexpresslyprovidedintheBEFTNRules.
Date:

By

PrintName

Title

(ParticipatingBankingCompany)

BangladeshBank

:_______________________________

PrintName

:_______________________________

Title

(Signature)

Acceptedthis________dayof_______,_______

By

:_______________________________

83

APPENDIXEIGHT
SAMPLEBEFTNORIGINATIONAGREEMENT

::WARNING::

BEFTNOriginationAgreementMustBeCustomizedFor

BEFTNOriginatorandApplication

BEFTNORIGINATIONAGREEMENT

THISAGREEMENTisenteredintoeffectiveasofthe__dayof________________,20___,by
and between ______________________, (the Originator), and _____________________
(Bank).

RECITALS

WHEREAS,theOriginatorhasrequestedthatBankpermitittoinitiateelectroniccreditand
debit entries (and Entry or Entries) for payment to accounts maintained at Bank and
otherBanks,bymeansoftheBangladeshElectronicFundsTransferNetwork(theBEFTN);
and

WHEREAS,BankiswillingtoprovidesuchservicestoOriginatorinaccordancewiththeterms
andconditionscontainedherein.

NOWTHEREFORE,inconsiderationofthemutualpromisescontainedherein,thesufficiency
ofwhichisherebyacknowledged,itisagreedasfollows:

AGREEMENT

1. TransmissionofEntries.

1.1. Bank,initscapacityasanoriginatingdepositBank,willtransmittheEntriesinitiatedbythe
OriginatorintotheBEFTNandwiththoseproceduresprovidedforhereinandasprovidedin
theBEFTNRules;assuchrulesmaybeamendedfromtimetotime.
1.2. TheOriginatorwillutilizeBanksoriginationsystemusingBEFTNformatorsuchotherformat
ormediumasthepartiesmaymutuallyagreeuponforthetransmittalofEntriestoBank.
1.3. AllEntrieswillbetransmittedtoBankinaccordancewiththeprocessingschedulesetforth
onAttachmentA(ProcessingSchedule).
1.4. ThetotalamountofEntriessentbytheOriginatorshallnotexceedtheestablishedlimitsset
forthonAttachmentB(ExposureLimit).

2. CompliancewithLaw,BEFTNRules.

2.1. TheOriginatorwillcomplywithallBEFTNRules,andapplicableregulationsandlaws(Rules
andLaws)withrespecttothesubjectmatterofthisagreement.Thespecificdutiesofthe
Originatorprovidedinthisagreementshallinnowaylimittheforegoingundertaking.

84

2.2. ItwillbethesoleresponsibilityoftheOriginatortoensurethatthetransmissionofEntries
andoriginationofBEFTNtransactionsareinfullcompliancewithallRulesandLaws.
2.3. The Originator will obtain written authorizations for consumer entries in accordance with
theBEFTNRulesandLaws,andshallretaintheoriginalorareasonablecopythereofforno
lessthantwo(2)yearsfollowingtheterminationorrevocationofsuchauthorization.

3. RejectionofEntries.

3.1. IntheeventthatanyEntriesarerejectedbytheBEFTNSystemforanyreason,itshallbethe
responsibilityoftheOriginatortoremakesuchentries.Bankshallhavenoresponsibilityto
reinitiateanyreturnedentriesuntilOriginatorremakessuchentriesinaccordancewiththe
BEFTNRules.
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 Banks sole
discretion.Inaddition,BankshallhavetherighttorejectanyEntrythatismadewhilethe
Originatorisindefaultofanyrequirementsofthisagreement,includingbutnotlimitedto
therequirementtomaintainanadequateaccountbalanceorlineofcredit.

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
reinitiatingisinaccordancewithapplicablesectionsoftheBEFTNRules.Bankwillnotreinitiate
anyreturnedentriesautomatically.

5. OriginatorError.

5.1. IftheOriginatordiscoversthatanyEntryithasinitiatedwasmadeinerror,itmustnotify
Bankoftheerrorwithin24hours.Insuchacase,Bankwillutilizeitsbesteffortstoinitiate
anadjustingentryorstopprocessingofanyonusEntry.ShouldBankbeunabletostop
theEntryfromposting,orifitistoolatetowithdrawtheitemfromtheBEFTNSystem,the
OriginatormayinitiateareversalfiletocorrecttheEntry,asprovidedforandabidingbythe
BEFTNRules.
5.2. ShouldareversalbecreatedforanindividualEntryorEntries,thereceiver(s)oftheEntries
mustbenotifiedbytheOriginatorofthereversalnolaterthanthesettlementdateofthe
reversingEntry.
5.3. Shouldareversalbecreatedforacompletefilereversal,theOriginatormustadviseBank
withinfive(5)businessdaysofsettlement.

6. Settlement.TheOriginatorandBankshallcomplywiththesettlementproceduresdescribedin
AttachmentC(Settlement).

7. Account Reconciliation. Entries transmitted by Bank will be reflected on Originators periodic

statement. Originator agrees to notify Bank immediately of any discrepancy between
Originators 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
periodicstatement,Originatoragrees thatBankwillnot beliableforanylossesresulting from
Originatorsfailuretogivesuchnotice.

8. Security Procedures. The Originator and Bank shall comply with the security procedures
describedinAttachmentD(SecurityProcedures).TheOriginatoracknowledgesthatthepurpose
ofthesecurityproceduresisforverificationoffileauthenticityandnottodetecterrorswithin

85

thetransmittedfileorindividualtransactions.Nosecurityprocedurefordetectionofanysuch
errorhasbeenagreeduponbetweentheOriginatorandBank.

9. Payment for Services. The Originator agrees to compensate Bank for providing the services
referredtohereinatthepricessetforthinAttachmentE.Thepricescontainedthereindonot
include,andOriginatorshallberesponsibleforpaymentof,anysales,use,excise,valueadded,
utilityorothertaxesrelatingtotheservicesprovidedforherein.BankmayamendthePricing
ScheduleatanytimeupondeliveryofnoticethereoftoOriginator.

10. LimitationofLiability.

10.1. BANKS 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
CONSEQUENTIALDAMAGESORFORANYLOSTORIMPUTEDPROFITSORREVENUESOR
COSTSOFCOVERARISINGFROMORRELATEDTOTHESERVICESPROVIDEDUNDERTHIS
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. ORIGINATORS EXCLUSIVE
REMEDIESFORANYANDALLCLAIMSRELATEDTOTHESERVICESPROVIDEDHEREUNDER
SHALLBELIMITEDTOTHEAMOUNTRECOVERABLEBYBANKFROMTHEBEFTNSYSTEM
OPERATOR, OR ANY OTHER SUB MEMBER PURSUANT TO THE BEFTN RULES OR ANY
APPLICABLEINDEMNITYAGREEMENT.

10.2. Bank will not be liable for any failure or delay in transmission of an Entry if such
transmissionwould(1)resultinBankshavingexceededanylimitationuponitsintraday
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
regulationofanyBangladeshgovernmentalregulatoryauthority.

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,MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

12. IndemnificationofBank.

12.1. TheOriginatorwillindemnifyBankifBankincursanyfinanciallossorliability(including
attorneysfeesandassociatedexpenses)duetothebreach,withrespecttoanyEntries
initiatedbytheOriginator,ofanyofthewarrantiesofanOriginatingBankcontainedin
the BEFTN Rules, except those due to the gross negligence of Bank. This includes
reimbursementbytheOriginatortoBankofanyfinesimposedonBankduetobreaches
oftheBEFTNRulesbytheOriginator.

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
associatedwithoraffectedbytheservicestobeperformedhereunder,includingbutnot
limitedtoanyreceiver,receivingBank,oranyfederalreservefinancialinstitution.

86

13. 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
specifiedbywrittennotice,andwillbeconsideredgiveneither:(i)whendeliveredinpersonto
the recipient specified below; (ii) when deposited in either registered or certified Mail, return
receiptrequested,postageprepaid;or(iii)whendeliveredtoanovernightcourierservice.

IftoBank:
IftoOriginator:
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
Attn:_________________________
Attn:_________________________

Bankshallbeentitledtorelyonanywrittennoticeorotherwrittencommunicationbelievedby
it in good faith to be genuine and to have been signed by an authorized representative of
Originator,andanysuchcommunicationshallbedeemedtohavebeensignedbysuchperson.
The names and signatures of authorized representatives of Originator are set forth in
Attachment F (Authorized Representatives). Originator may add or delete any authorized
representativebywrittennoticetoBanksignedbyanauthorizedrepresentativeotherthanthat
beingaddedordeleted.Suchnoticeshallbeeffectiveonthesecondbusinessdayfollowingthe
dayofBanksreceiptthereof.

14. Originator Data Retention. Originator will retain data on file adequate to permit remaking of
Entriesforten(10)daysfollowingthedateoftheirtransmittalbyBankasprovidedherein,and
shallprovidecopiesofsuchdatatoBankuponitsrequest.

15. Assignment. Originator may not assign this agreement or any of its rights or obligations
hereunderwithoutthepriorwrittenconsentofBank.Thisagreementshallbebindinguponand
inuretothebenefitofthepartiesheretoandtheirrespectivelegalrepresentatives,successors
andassigns.

16. No Third Party Beneficiaries. The terms, representations, warranties and agreements of the
partiessetforthinthisAgreementarenotintendedfor,norshalltheybeforthebenefitofor
enforceableby,anypersonorentitythatisnotapartytothisagreement.

17. Severability.Ifanyprovisionofthisagreementisheldtobeunenforceable,theunenforceable
provisionshallbeconstruedasnearlyaspossibletoreflecttheoriginalintentofthepartiesand
theremainingprovisionsshallremaininfullforceandeffect.

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
ForceMajeureEventmeansanunforeseeableeventbeyondthereasonablecontrolofBank,
includingbutnotlimitedto:anactofGod;fire;flood;labourstrike;sabotage;fiberordataline
cut;lackofordelayintransportation;governmentcodes,ordinances,laws,rules,regulationsor
restrictions;warorcivildisorder.

19. Waiver.Banksfailuretoinsistuponstrictperformanceofanyprovisionofthisagreementshall
notbeconstruedasawaiverofanyofitsrightshereunder.

20. Termination.TheOriginatormayterminatethisagreementatanytimeupondeliveryofthirty
(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

87

agreement shall not affect any of the Originators obligations arising pursuant to the terms of
thisagreementpriortosuchtermination.

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 Peoples Republic of
Bangladesh.

22. EntireAgreement.Thisagreement,togetherwithanyattachmentshereto,constituteoneand
thesamelegallybindinginstrumentandtheentireagreementbetweentheOriginatorandBank
with respect to the subject matter hereof, and supersedes all prior offers, contracts,
agreements,representationsandunderstandingsmadetoorwiththeOriginator,whetheroral
orwritten,relatingtothesubjectmatterhereof.Allamendmentstothisagreementshallbein
writingandsignedbyauthorizedrepresentativesoftheparties.

INWITNESSWHEREOF,theundersignedhavedulyexecutedtheAgreementbytheirdulyauthorized
officers.

ORIGINATOR
BANK
By

:_______________________
By

:_______________________

PrintName

:_______________________

PrintName

Title

:_______________________

:_______________________

Title

: _______________________

ATTACHMENTA

ProcessingSchedule

ThefollowingscheduleisfortheuseoftheOriginatortodeterminedeadlinesforsendingorigination
files to Bank. Files received after these deadlines may not be guaranteed delivery to the BEFTN
Operatorfornextdaysettlement.

1.
Payroll Credits: All payroll credit origination will be sent to the Bank by 1:00 p.m. time two
businessdaysbeforethesettlementdateofthesubjectEntries.

2.
DebitEntry: Thedatafile containingdebitentryinformationwilltransmitted toBankBEFTN
Departmentby3:00p.m.onebusinessdaybeforethesettlementdateofthesubjectEntries.
Allfilesreceivedaftertheabovereferenced3:00p.m.deadlinewillbeprocessedthefollowing
businessday.

3.
OtherCredits:AllothercreditoriginationEntriesmustbesubmittedby6:00p.m.businessday
beforethesettlementdateofthesubjectEntries.

NotetoOriginator

Credit items sent earlier than two days before intended settlement date will be warehoused with
Bankuntiltwodaysbeforetheintendedsettlementdate.

Debititemssentearlierthanonedaybeforetheintendedsettlementdatewillbewarehousedwith
Bankuntilonedaybeforetheintendedsettlementdate.

IfyouintendtowarehouseitemswithBank,advancenotificationofyourintentionsisrequired.

::Warning::

SampleWordingOnlyAllProvisionsofAttachments

MustBeCustomizedForEachOriginatorandApplication

ATTACHMENTB

ExposureLimit

The total daily limit of all originated debit and credit Entries combined will be set equal to the
average daily balance in the Originators Bank cash management account during the preceding
calendarquarter,andwillbeadjustedonaquarterlybasis.ThecurrentlimitisTK5lakhperday.

TheOriginatorsdailylimitfororiginatedcreditEntrieswillbethelesseroftheOriginatorscurrent
balanceintheOriginatorsBankcashmanagementaccountorTk1lakh.

The daily limit for originated debit Entries to consumer accounts will be equal to the available
balanceintheOriginatorslineofcreditloanwithBank.TheOriginatorwillberequiredtomaintain
anavailableloanbalanceofatleastTk1lakhatalltimes.

::Warning::

SampleWordingOnlyAllProvisionsofAttachments
MustBeCustomizedForEachOriginatorandApplication

ATTACHMENTC

Settlement

TheOriginatorwillprovideimmediatelyavailablefundstooffsetanycreditentriesoriginatedbyit
notlaterthanthecorrespondingsettlementdate.

TheOriginatorwillreceiveimmediatelyavailablefundsforanyelectronicdebitentriesinitiatedbyit
notlaterthanthesettlementdateoftheitems.Provisionsmaybemadeforholdingaccountstobe
maintainedforpostingofanyreturndebititemsreceived,asstatedinthisagreementandabidingby
theBEFTNRules.

The Originator will promptly provide immediately available funds to indemnify Bank if any debit
itemsarerejectedafterBankhaspermittedtheOriginatortowithdrawimmediatelyavailablefunds,
shouldfundsnotbeavailableintheOriginatorsaccountstocovertheamountoftherejecteditems.
Inordertoprovideavailablefundstocovertheamountofrejecteditems,Originatorwillberequired
to maintain an available lineofcredit loan with Bank in an amount of at least 5% of the previous
monthstotaldebitentryoriginations.

::Warning::
SampleWordingOnlyAllProvisionsofAttachments
MustBeCustomizedForEachOriginatorandApplication

ATTACHMENTD

SecurityProcedures

The Originator is required to utilize the Banks security procedures for allorigination activity. Dual
approval of all template and payment initiation functions will be required. The single entry
maximumtransactionTakalimitwillbesetatTK______forBEFTNuser.Alloriginatedfilesinexcess
of TK _________ sent to Bank will require a telephone verification by Bank with an Originator
AuthorizedRepresentative(seeAttachmentF)beforethefileswillbereleased.

AlloriginationfilessenttoBankwillrequireasecondverificationoffileentryandTakatotalsbyan
OriginatorAuthorized Representative. Thissecond verificationcanbesubmittedbyelectronicmail
orfacsimilewithsignaturetoBanksBEFTNDepartment.

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
transfersintheabsenceofpropersupervisionandsafeguards,andagreestotakereasonablesteps
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
suchinformationhasbeenaccessedbyanunauthorizedindividual,theOriginatorwillverballynotify
Bank immediately, followed by written confirmation. The occurrence of such notification will not
affectanytransfersmadeingoodfaithbyBankpriortothenotificationandwithinareasonabletime
periodtopreventunauthorizedtransfers.

::Warning::

SampleWordingOnlyAllProvisionsofAttachments

MustBeCustomizedForEachOriginatorandApplication

ATTACHMENTE

AuthorizedRepresentatives

All BEFTN transaction files/listings must be delivered with a transmittal document with authorized
signature(s).

Date

:________________________

OriginatorName
:________________________

CompanyIDNumber :________________________

The______signaturesbelowarethesignaturesofemployeesvestedbyourBoardofDirectors,who
have full authority to sign transmittal registers to be used in conjunction with the submission of
BEFTNfiles.Thenumberofsignaturesthatarerequiredtosubmitafileforprocessing:______

Name
Phone#
Signature

AuthorizedSignature :________________________

Title

:________________________

Date

:________________________

::Warning::
SampleWordingOnlyAllProvisionsofAttachments
MustBeCustomizedForEachOriginatorandApplication