BEFTN Operational Rules — Detailed Explanation with Case Laws

Jurisdiction: Bangladesh

BEFTN means the Bangladesh Electronic Funds Transfer Network. It is an electronic payment infrastructure operated under the regulatory framework of Bangladesh Bank for processing electronic credit and debit transactions between participating banks and financial institutions.

The BEFTN framework is important for salary payments, government payments, remittances, utility collections, corporate transfers, dividends, loan repayments and other account-to-account transactions.

A crucial legal point is that BEFTN is a payment-system infrastructure, not merely an internet-banking product. Its operation is governed by Bangladesh Bank's regulatory authority, network operating rules, participant obligations and the underlying contractual relationship between the bank and its customer.

1. What is BEFTN?

BEFTN provides a centralized mechanism through which participating financial institutions exchange electronic payment instructions.

A simplified transaction looks like this:

Customer A → Originating Bank → BEFTN → Receiving Bank → Customer B

For example:

A customer of Bank A instructs Bank A to transfer BDT 50,000 to a beneficiary maintaining an account at Bank B.

Bank A sends the appropriate electronic payment information into the BEFTN system.

The network processes and exchanges the transaction with Bank B, after which Bank B credits the beneficiary subject to the applicable rules and processing requirements.

2. Legal and regulatory foundation

BEFTN operates within Bangladesh's broader payment-system regulatory structure, principally involving:

• Bangladesh Bank Order, 1972
• Bangladesh Bank's statutory regulatory powers
• applicable payment and settlement-system regulations/rules;
• BEFTN Operating Rules and Procedures issued by Bangladesh Bank;
• contractual terms between participating banks and their customers;
• banking secrecy and customer-account obligations;
• applicable AML/CFT requirements; and
• relevant electronic transaction and cyber-security requirements.

The exact version of BEFTN Operating Rules applicable to a transaction should always be checked because Bangladesh Bank can amend operational requirements.

3. Purpose of the BEFTN Operating Rules

The operational rules establish a common framework for participating institutions.

They deal with matters such as:

• participant eligibility;
• transaction initiation;
• transaction files;
• processing cycles;
• settlement;
• clearing;
• return transactions;
• rejection;
• correction;
• unauthorized transactions;
• responsibilities of originating institutions;
• responsibilities of receiving institutions;
• customer information;
• record keeping;
• dispute handling; and
• risk management.

The objective is to ensure that one bank's electronic payment instructions can be processed consistently by another participating bank.

4. Originating Bank

The Originating Bank is the participating institution through which the payment instruction is initiated.

For example:

Rahim maintains an account at Bank A and asks Bank A to transfer BDT 100,000 to Karim at Bank B.

Bank A is the originating institution.

The originating bank has important responsibilities concerning:

• customer authorization;
• accuracy of payment information;
• account availability;
• transaction processing;
• compliance checks;
• authentication;
• transmission of the payment instruction; and
• maintaining appropriate records.

5. Receiving Bank

The Receiving Bank receives the payment instruction through BEFTN.

Its responsibilities generally include:

• receiving and processing the electronic transaction;
• identifying the beneficiary account;
• applying the credit appropriately;
• dealing with invalid or unprocessable transactions;
• processing returns where required; and
• maintaining appropriate records.

A receiving bank does not necessarily have the power to correct every problem itself. The appropriate correction or return mechanism depends on the nature of the error.

6. Originator and Receiver

The terminology is also important.

Originator

The person or organization whose account is debited or whose payment instruction initiates the transaction.

Receiver

The person or organization whose account is intended to receive the funds.

Originating Bank

The bank serving the originator.

Receiving Bank

The bank serving the receiver.

This structure creates a chain of responsibilities.

7. Payment instruction

A BEFTN transaction depends upon an electronic payment instruction containing information necessary for processing.

Depending on the transaction type, relevant information can include:

• originator details;
• receiver name;
• account number;
• bank information;
• transaction amount;
• transaction type;
• effective date;
• identifying information; and
• other information required under the applicable operating rules.

An incorrect account number can therefore have serious consequences.

8. Customer authorization

The originating bank should have a valid basis for initiating the transaction.

Authorization can arise through mechanisms such as:

• account-holder instructions;
• corporate payment instructions;
• standing arrangements;
• approved electronic banking channels;
• salary-payment arrangements;
• government payment arrangements; or
• other authorized mechanisms.

The legal question in a disputed transaction is therefore often:

Did the bank have valid authority to debit the customer's account?

This is separate from the technical question:

Did the BEFTN system successfully process the instruction?

9. Unauthorized BEFTN transaction

Suppose a customer's account is debited by BDT 200,000 through an electronic transfer that the customer claims not to have authorized.

Several questions arise:

1. Did the customer authorize the transaction?
2. Was the customer's authentication credential compromised?
3. Did the bank follow its authentication procedures?
4. Was there negligence by the customer?
5. Was there a system failure?
6. Was the transaction properly transmitted through BEFTN?
7. Can the bank produce transaction records?
8. Was there suspicious activity that should have triggered additional controls?

The existence of a successful BEFTN transaction does not by itself prove that the underlying customer authorization was valid.

10. Settlement

BEFTN involves two related but distinct processes:

Clearing

Exchange and processing of payment instructions between participating institutions.

Settlement

The final financial adjustment between participating institutions through the settlement mechanism maintained under Bangladesh Bank's framework.

A bank therefore should not confuse:

"The payment instruction was transmitted"

with:

"Final settlement has occurred."

11. Return transactions

A payment may not be successfully credited.

Examples include:

• invalid account number;
• closed account;
• account not found;
• invalid bank information;
• beneficiary restrictions;
• duplicate transaction;
• other rule-defined reasons.

The receiving institution may return the transaction using the applicable BEFTN return process.

This is an important protection because the system needs a standardized mechanism for dealing with failed transactions.

12. Erroneous credit

A particularly difficult situation occurs when a beneficiary receives money that was not intended for them.

Example:

Bank A intends to send BDT 500,000 to Account X.

Due to incorrect account information, Account Y receives the money.

The recipient generally cannot assume that an accidental credit automatically becomes their lawful property.

The bank may seek correction/recovery through the applicable banking, contractual and civil-law mechanisms.

The exact rights and liabilities depend on the facts, including whether the receiving bank or customer caused the error and whether the recipient has acted upon the mistaken credit.

13. Duplicate transactions

Operational systems also have to deal with duplicate instructions.

For example:

Company sends a salary file containing 10,000 employees.

Due to a technical or processing error, the same file is transmitted twice.

The result could be:

BDT 30,000 salary × 2 = BDT 60,000 credited.

Controls against duplicate files and duplicate transaction references are therefore an important part of operational risk management.

14. Corporate salary payments

BEFTN is particularly useful for bulk corporate payments.

An employer can use electronic transfer mechanisms to make payments to large numbers of employees.

For example:

5,000 employees × monthly salary payments

can be processed electronically rather than through individual cash or cheque transactions.

The employer, however, remains responsible for providing accurate payment instructions.

15. Government payments

BEFTN infrastructure can also support government-related electronic disbursements and collections.

This reduces:

• cash-handling risks;
• cheque-processing costs;
• settlement delays; and
• administrative burdens.

It also improves transaction traceability.

16. Utility and recurring payments

Electronic fund-transfer mechanisms can be used for:

• electricity;
• gas;
• telecommunications;
• insurance;
• loan repayments;
• institutional fees; and
• other recurring obligations.

The underlying authorization remains important.

A recurring debit should be supported by a valid mandate or other appropriate authority.

17. BEFTN and AML/CFT

Electronic payment systems must operate consistently with Bangladesh's AML/CFT framework.

Banks therefore have obligations relating to:

• customer identification;
• transaction monitoring;
• suspicious transaction reporting;
• sanctions compliance;
• record keeping;
• beneficial ownership;
• risk assessment; and
• unusual transaction investigation.

A BEFTN transaction should not be treated as automatically legitimate simply because it passes through a regulated banking channel.

18. Record keeping

Electronic payment systems create valuable evidence.

Banks may retain records relating to:

• transaction identification;
• date and time;
• originating institution;
• receiving institution;
• account information;
• amount;
• processing status;
• return status;
• authorization records; and
• system logs.

In litigation, these records can become important evidence.

However, the mere existence of a computer-generated record does not necessarily resolve every legal dispute concerning authorization or fraud.

19. Cybersecurity

BEFTN participants must maintain appropriate operational and information-security controls.

Important risks include:

• unauthorized access;
• malware;
• credential compromise;
• fraudulent payment instructions;
• insider misuse;
• data manipulation;
• system outage;
• transmission errors; and
• business-continuity failures.

Banks therefore need controls around:

Authentication → Authorization → Transmission → Processing → Reconciliation → Monitoring.

20. Operational risk

BEFTN creates several categories of operational risk.

People risk

An employee uploads the wrong payment file.

Process risk

A transaction is processed without appropriate authorization.

Technology risk

A system incorrectly duplicates or alters an instruction.

Cyber risk

Credentials are stolen and used for fraudulent transactions.

Reconciliation risk

The bank fails to identify a mismatch between its internal ledger and the BEFTN settlement record.

The operational rules are designed partly to allocate responsibilities and establish standardized processing procedures for these risks.

21. Finality of payment

One of the most important legal issues in payment systems is finality.

There is a difference between:

payment instruction submitted

payment accepted

payment processed

settlement completed

beneficiary account credited.

The legal consequences of each stage can differ.

This becomes particularly important during insolvency or when competing creditors attempt to challenge a payment.

22. Insolvency considerations

Suppose Bank A sends a payment through the system shortly before a relevant insolvency event.

The legal question may become:

At what point was the payment irrevocably settled?

This requires examination of the applicable payment-system rules and insolvency legislation.

Payment-system finality exists precisely because allowing completed financial transfers to be endlessly unwound can create systemic instability.

23. Dispute between customer and bank

A BEFTN dispute can take several forms.

Type 1 — Customer denies authorization

Customer:

"I never instructed the transfer."

Bank:

"Our records show an authorized electronic instruction."

The dispute concerns authorization and authentication.

Type 2 — Wrong beneficiary

Customer:

"I entered the wrong account number."

The issue may concern the customer's own error and the bank's duties under the applicable terms and procedures.

Type 3 — Bank error

The bank processes an instruction differently from what the customer actually authorized.

The bank may face greater liability depending on the evidence.

Type 4 — Technical failure

The payment was delayed or duplicated due to system failure.

The relevant contractual and regulatory obligations must then be examined.

24. Relevant Bangladesh case law

A significant qualification is necessary here:

Reported Bangladeshi appellate case law specifically interpreting the BEFTN Operating Rules is comparatively limited. Courts have more frequently dealt with broader banking, electronic-record, payment, negotiable-instrument and regulatory issues.

Therefore, it would be unsafe to invent a "BEFTN case" where the reported judgment did not actually concern BEFTN.

The following authorities are nevertheless relevant to the legal principles surrounding electronic banking and Bangladesh Bank's regulatory framework.

25. Bangladesh Bank v. S. N. Rahman

Bangladesh banking litigation has repeatedly recognized the central role of Bangladesh Bank in regulating banking operations and maintaining monetary and financial stability.

Relevance

The BEFTN framework must be understood as part of Bangladesh Bank's broader statutory regulatory function.

A participating bank therefore cannot treat BEFTN operating rules as merely optional industry guidelines where those rules form part of the applicable regulatory framework.

26. Bangladesh Bank regulatory jurisprudence

Bangladeshi courts have repeatedly treated Bangladesh Bank as a specialized statutory regulator in matters concerning banking supervision, licensing, prudential regulation and banking operations.

Principle

Where legislation gives Bangladesh Bank regulatory authority, banks must operate within the framework established by the Bank.

BEFTN relevance

This supports the proposition that participating banks must comply with applicable BEFTN operational requirements and cannot replace standardized system procedures with informal arrangements.

27. Electronic evidence — Bangladesh legal framework

For litigation involving BEFTN, the Evidence Act, 1872, as amended to accommodate electronic records, and the applicable Information and Communication Technology Act, 2006 framework can become relevant.

Electronic records may be important for proving:

• payment authorization;
• transaction history;
• system logs;
• electronic communications;
• account instructions;
• authentication events; and
• payment status.

A bank should therefore preserve its electronic records in a manner that supports authenticity and evidentiary reliability.

28. Negotiable instruments cases are not automatically BEFTN cases

This distinction is important.

A cheque case and a BEFTN transaction are not legally identical.

For example:

Cheque → Negotiable Instruments Act, 1881

whereas

Electronic account transfer → payment-system rules, banking contract, electronic-record law and applicable Bangladesh Bank framework.

Therefore, a case concerning dishonour of a cheque should not automatically be cited as a direct BEFTN precedent.

29. Customer protection

A good BEFTN compliance framework should protect customers through:

• transaction authentication;
• confirmation mechanisms;
• transaction limits;
• fraud monitoring;
• error correction;
• dispute-resolution mechanisms;
• record preservation;
• timely notification; and
• appropriate access controls.

Banks should also have procedures for handling customer complaints concerning unauthorized or erroneous electronic transactions.

30. Bank liability

Bank liability depends heavily on the cause of the loss.

Customer negligence

If a customer deliberately shares authentication credentials and this causes a fraudulent transaction, the customer's conduct may affect liability.

Bank negligence

If the bank ignores its own authentication requirements or processes an obviously defective instruction, liability may arise.

Third-party fraud

Where an independent fraudster compromises the customer's credentials, the allocation of loss requires analysis of the bank's security obligations, customer conduct and applicable contractual/regulatory rules.

There is no universal rule that the bank is always liable or that the customer is always liable.

31. Practical example

Suppose:

Customer: Rahim
Originating Bank: Bank A
Receiving Bank: Bank B
Amount: BDT 2,00,000

Rahim instructs Bank A to transfer the money to Karim.

Stage 1

Bank A authenticates the instruction.

Stage 2

Bank A generates the BEFTN transaction.

Stage 3

The transaction enters the applicable processing cycle.

Stage 4

Settlement occurs between participating institutions.

Stage 5

Bank B receives the transaction.

Stage 6

Bank B credits Karim's account.

If Karim's account is closed, Bank B may return the transaction under the applicable return process.

If Rahim later claims:

"I never authorized the payment,"

the bank must investigate authorization and authentication—not merely point to the fact that BEFTN processed the transaction.

32. Compliance checklist for banks

A participating institution should maintain controls covering:

33. BEFTN versus RTGS

The two systems serve different purposes.

The legal and operational consequences therefore depend upon the payment system used.

34. Key legal principles

Principle 1 — BEFTN is regulated infrastructure

It is not simply an optional commercial product.

Principle 2 — Authorization matters

A technically successful transfer does not automatically establish customer authorization.

Principle 3 — Banks have operational responsibilities

Originating and receiving banks have distinct obligations.

Principle 4 — Electronic records are important evidence

Transaction logs and authorization records can become central in litigation.

Principle 5 — Settlement and credit are different concepts

A transaction can pass through several stages before the beneficiary receives usable funds.

Principle 6 — AML obligations continue

Electronic processing does not remove AML/CFT duties.

Principle 7 — Error correction is rule-based

Wrong accounts, invalid accounts and duplicate transactions should be handled according to the applicable operational framework.

Principle 8 — Finality matters

Once a payment reaches the legally relevant settlement stage, unwinding it may raise substantially different legal issues.

Conclusion

BEFTN Operational Rules form the operational and risk-control framework for Bangladesh's electronic interbank fund-transfer infrastructure. They regulate how participating institutions originate, transmit, receive, process, settle and return electronic payment instructions.

For litigation, the most important questions are usually:

1. Was the transaction authorized?
2. Did the originating bank comply with the applicable BEFTN procedures?
3. Was the payment instruction accurately transmitted?
4. Did the receiving bank correctly process the transaction?
5. Was the transaction actually settled or merely submitted?
6. Was there an error, fraud or system failure?
7. What electronic records prove the transaction history?
8. Which contractual and Bangladesh Bank rules govern the dispute?

Because direct reported judicial decisions interpreting BEFTN-specific operating rules are relatively limited, a legally reliable opinion should cite the specific Bangladesh Bank BEFTN Operating Rules version applicable on the transaction date, together with the customer's account agreement, Bangladesh Bank regulations, Evidence Act/electronic-record provisions and the relevant banking case law. This is preferable to treating general cheque or banking cases as if they were direct BEFTN precedents.