Bank Drafts, Pay Orders, IFSC, SWIFT and Core Banking Concepts

1. Why banking has more than one payment instrument#

A customer cheque depends on the account holder's available balance or permitted drawing facility when the bank processes it. Banks also issue pre-funded bank instruments such as demand drafts and pay orders. Separately, customers can initiate electronic transfers using identifiers such as IFSC. International institutions communicate through secure messaging networks such as SWIFT.

All of these transfer or support payment obligations, but they are not interchangeable products.

2. Demand Draft — DD#

A demand draft is a bank-issued instrument traditionally used to direct payment of a specified amount to the named beneficiary through the bank's arrangements. The purchaser pays or authorises debit before the bank issues it, so the draft is conventionally described as a prepaid bank instrument.

Example: A candidate needs to submit a fee to a college that accepts a demand draft payable at a designated location. The candidate requests the bank to issue a draft favouring the institution. The bank collects the amount/charges and issues the instrument.

Parties to remember#

• Purchaser/applicant: Requests the draft and funds it.
• Issuing bank: Creates the draft/payment instruction.
• Beneficiary/payee: Named recipient.
• Paying office/bank branch: Makes payment under the instrument/bank arrangement.

The bank is responsible under its validly issued draft; do not confuse it with a customer's cheque drawn by a private account holder.

Why drafts were popular#

• Institution-to-institution remittance where electronic banking was less universal.
• Acceptance by educational and Government institutions.
• Bank-issued, prepaid format reduced some account-holder dishonour risk.
• Documented beneficiary/payment instructions.

DDs are now less prominent because of NEFT, RTGS, UPI and other electronic alternatives, but remain frequently asked in exams and some institutional processes.

3. Pay Order / Banker’s Cheque#

A pay order or banker’s cheque is also a bank-issued prepaid payment instrument, historically associated particularly with local payment arrangements. Product naming and geographical applicability depend on bank operations and current systems.

DD vs pay order — conceptual comparison#

Caution: The traditional local/outstation distinction is an exam concept, not a promise that all banks currently implement every product the same way across their Core Banking systems. Verify bank-specific procedures.

4. Cheque vs demand draft vs pay order#

Exam trap: “Demand draft can never be dishonoured for any reason” is too broad. Even bank-issued instruments can face fraud, invalidity, stale-date, duplicate/loss, cancellation or legal issues. The accurate point is that ordinary drawer insufficient-funds risk differs because a draft is funded before issue.

5. Rules on drafts and other instruments#

RBI customer-service instructions have required that demand drafts, pay orders and banker’s cheques dated from the relevant period should not be paid if presented beyond three months from the date of instrument. The policy also contains rules about instrument issue, encashment, cancellation and duplicates.

For remittances of ₹50,000 and above, RBI's customer-service framework has specified bank-account debit or payment against approved banking instruments rather than cash issue. Bank KYC/AML controls, latest directions and product rules still apply. Because amounts and processes may change, keep exact thresholds in current-data records.

Cancellation / duplicate draft#

If a DD is lost or needs cancellation, the purchaser may need to satisfy:

• application and identity/transaction verification;
• issuing-bank records;
• beneficiary/payment status;
• indemnity/documentation as applicable;
• bank charges and internal control requirements.

A duplicate is not an automatically valid second payment claim. The bank must prevent the original and duplicate being encashed separately.

6. Electronic remittance has a different architecture#

Electronic fund transfers are not simply cheques converted to PDF. The customer submits a payment instruction through a bank channel; the bank validates it; the authorised system transfers the instruction/funds and reports status.

Examples include:

• NEFT: National Electronic Funds Transfer;
• RTGS: Real Time Gross Settlement;
• IMPS: Immediate Payment Service;
• UPI: Unified Payments Interface.

Detailed payment-rail definitions belong to Module 11. This lesson concentrates on identifying where the transfer goes and how the bank runs its core system.

7. IFSC — Indian Financial System Code#

IFSC is an 11-character alphanumeric code identifying a bank branch for systems such as NEFT and RTGS, under the applicable network registry.

Typical format:

AAAA0BBBBBB

• Characters 1–4: Alphabetic bank identifier.
• Character 5: 0 (zero).
• Characters 6–11: Branch identifier (six characters).

Illustrative code only: ABCD0123456. This is a shape example, not a real or verified branch code.

Why IFSC matters#

Two branches may have customers with similar names or account-number patterns. IFSC helps route a payment to the correct participating bank/branch within the system.

Safety principle: Before transferring money, confirm the account number, recipient, bank and IFSC, using an official source or trusted banking channel. An IFSC alone does not prove that the payee is legitimate.

8. IFSC vs MICR#

Both can appear on a cheque leaf. They are different codes, with different roles. Never insert the MICR code in an IFSC input field because both seem “bank codes.”

9. What is SWIFT?#

SWIFT is the Society for Worldwide Interbank Financial Telecommunication, a member-owned cooperative providing a secure financial-messaging network and standards for financial institutions.

A payment message can carry details such as:

• sending institution;
• receiving institution;
• beneficiary information;
• currency and amount;
• payment reference;
• compliance/routing information.

Core distinction: SWIFT is a messaging infrastructure, not itself a commercial bank holding the beneficiary's deposit, nor the universal settlement account where every transfer clears. Actual money movement/settlement uses banks and relevant settlement or correspondent arrangements. This distinction is confirmed by Swift's own public explanation.

10. SWIFT BIC — Business Identifier Code#

A BIC is an internationally standardised identifier for businesses/institutions in financial messaging. Often called a SWIFT code, a BIC commonly has 8 characters, with an optional 3-character branch identifier giving an 11-character form.

Teaching structure:

• 4-character institution/business code;
• 2-character country code;
• 2-character location code;
• optional 3-character branch code.

Illustrative only: ABCDINBBXXX is a made-up structure example, not a verified real institution.

Do not confuse this BIC structure with IFSC merely because both can have 11 characters. IFSC includes a 0 in position five; BIC follows a different international standard.

11. Cross-border transfer — simplified illustration#

A customer in India wants to pay an overseas supplier:

Customer request
→ Indian remitting bank
→ compliance/FX checks
→ secure cross-border financial messages (often SWIFT)
→ correspondent/intermediary bank(s), if needed
→ beneficiary bank
→ beneficiary account.

The actual route can vary by currency, corridors, bank relationships and settlement architecture. A SWIFT message being sent does not guarantee the beneficiary has already received cleared funds.

12. Nostro, Vostro and correspondent banks#

These concepts help explain how cross-border settlements work:

• Nostro: Our account with you — a bank's account held with another bank, often abroad and in foreign currency.
• Vostro: Your account with us — the other bank's account on a bank's books.
• Correspondent banking: Arrangements where one financial institution provides payment, account or related services to another.

Example: An Indian bank maintains a USD account with a bank in New York. From the Indian bank's viewpoint it is a Nostro account; from the US bank's viewpoint, a corresponding account is Vostro.

For banking exams, this distinction is often more valuable than memorising every SWIFT message type.

13. Core Banking Solution — CBS#

Core Banking Solution (CBS) is a centralised technology platform used by banks to maintain customer-account information and process services across branches/channels.

In a non-networked legacy arrangement, a customer might be tied to one branch's local records. With CBS, authorised staff/channels can access a common banking application and serve the customer according to permissions and bank policy.

Core functions#

• deposit and account records;
• customer master / KYC linkage;
• transactions and account balances;
• interest/charges processing;
• loan disbursement, schedules and repayments;
• clearing/payment-system integration;
• audit trails, reporting and general-ledger interfaces.

CBS is not itself an electronic funds-transfer rail like NEFT or UPI. CBS is the bank's processing environment; payment rails move instructions between participants.

14. Anywhere banking#

Anywhere banking refers to the ability to receive permitted services across the bank's branch/channel network because data and processes are centralised.

It does not mean a customer can access any bank's account data at any institution. Core banking usually connects branches of the same bank; interbank transfers require payment systems or permitted networks.

15. Core banking vs digital channels#

Example: A customer authorises a UPI payment on an app. The bank's systems check account/permissions using its core architecture, while the UPI network carries the interbank payment process. App, CBS and network are different layers.

16. Maker–checker control#

Banks use maker–checker or four-eye controls for sensitive operations:

• Maker: Enters or initiates the instruction.
• Checker / authoriser: Independently reviews and authorises within delegated powers.

Common uses include:

• large-value transaction authorisation;
• demand draft issuance/cancellation;
• changes to customer details;
• account maintenance;
• GL adjustments;
• exception handling.

The goal is to reduce unchecked unilateral actions. Maker–checker does not remove the need for logs, segregation of duties and oversight.

17. Real-time posting vs batch processing#

Banks process some events immediately and others in controlled batches:

• Real-time processing: Transaction record updated as instruction is processed.
• Batch processing: Groups of tasks executed at scheduled intervals.

Examples: A balance enquiry may read current ledger data. End-of-day interest accrual or reporting may be handled by a scheduled batch. The distinction concerns processing design; it is not identical to NEFT vs RTGS in every case.

18. End-of-day and reconciliation#

A bank must reconcile records between:

• customer sub-ledgers;
• general ledger;
• suspense/clearing accounts;
• external payment-system positions;
• cash and vault records where applicable;
• correspondent-account statements;
• settlements and exceptions.

Reconciliation ensures that entries expected to match actually agree, and exceptions are investigated.

Example#

A cheque has been confirmed as paid externally, but the internal suspense account still shows an unsettled entry. Reconciliation flags the difference for investigation. This is essential because a payment can pass through several systems before all records agree.

19. Audit trail and user permissions#

CBS tracks transactions through electronic logs and access controls. Good control design records:

• initiator / authoriser;
• timestamps;
• transaction reference;
• before/after values where relevant;
• exceptions/overrides;
• system response and status.

An audit trail is not a substitute for careful evidence analysis, but it improves accountability and helps investigate exceptions.

20. Branch operational examples#

A. DD purchase: A customer requests a bank draft for a Government tender. Staff verifies identity, payment/funding, payee and issuance approval. CBS records the obligation and appropriate accounting entry; the customer receives the issued draft.

B. Wrong IFSC: Customer initiates NEFT with incorrect routing details. The transaction may fail/return or be handled as per system rules; never promise that an incorrect IFSC is harmless merely because the recipient name was typed correctly.

C. Overseas transfer: SWIFT communicates an instruction, while settlement may take place through correspondent accounts and foreign-payment infrastructure.

D. Anywhere banking: A customer opened an account at Branch A and visits Branch B of the same bank. Under permitted CBS operations Branch B may provide services without opening a second account.

21. Common confusions — Lesson 13-04#

• Customer cheque vs bank draft: Drawer and funding structure differ.
• DD vs pay order: Both bank-issued; older local/outstation distinctions need current operational context.
• IFSC vs BIC/SWIFT code: Domestic routing code vs international business identifier/messaging.
• SWIFT vs settlement: Messaging does not itself move funds in bank settlement accounts.
• CBS vs UPI: Core ledger platform vs interbank interface/rail.
• Maker–checker vs audit: Dual authorisation helps prevent errors; audit helps review records and controls.
• Anywhere banking vs any bank: Service across the same bank's authorised network, not universal access to competitors.

Quick check — BA-13-04#

1. Who draws the ordinary customer cheque?
   Answer: Customer/account holder.
2. Who issues a demand draft?
   Answer: Bank.
3. What is the fifth character of a standard IFSC?
   Answer: Zero (0).
4. Does SWIFT itself hold and settle all cross-border funds?
   Answer: No; it is secure financial messaging.
5. What does CBS stand for?
   Answer: Core Banking Solution.
6. Why use maker–checker?
   Answer: Independent authorisation and segregation of duties.