Key points of this lesson, in order.
Cheques, still relevant in some markets
What you will learn
Your objective. By the end of this lesson, you will be able to explain cheques, still relevant in some markets. A cheque is a written, signed instruction from an account holder to a bank to pay a named payee a stated amount from the drawer account.
Why it matters. For an analyst, cheque work is mostly about the exceptions.
Chapter objective: Learner compares cash, cheques, cards, direct debits, credit transfers, and digital wallets, and selects the right instrument for a given business need based on speed, cost, risk, and reversibility. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Cheque definition
- Cheque imaging
- The return process
- Stop payment
- Cheque exceptions
- Cheque migration
Key terms
Market practice: An agreed way of using a message standard in a particular market or community, covering field usage, codes and validation rules.
Clearing: The process of exchanging payment instructions between banks and calculating what each bank owes the others.
Capture: The step in a card transaction where the merchant collects the authorised amount from the issuer, usually when goods are shipped.
Payment flow diagram showing Cheques, still relevant in some markets.
Practise this lesson
Exercise
Handle the exception described in this lesson the way the lesson prescribes.
Use the exception type, the reason code and the recovery path in this lesson.
- What to do. State what happened, what the correct action is, what must not be done, and what the post-incident review should capture.
Correct result. The correct action is the one the lesson prescribes for this exception type, with the right reason code and the right message. The payment must not be resent without checking whether it already settled, because that creates a duplicate.
Why. An exception handled wrongly is worse than the exception itself. A duplicate payment is a loss, and an unlearned exception will happen again.
Check your understanding
Practice question
A retailer wants customers to pay instantly at the till and also wants to offer pay-later instalments online. A BA is asked which instruments these are. What is the correct mapping?
Takeaway and next step
What to remember
An analyst should never assume cheques are gone, and should always check the local market practice.
Follow Rs 5,00,000 through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Cards, how a card payment really works".
Transcript and full text
Show transcript
A cheque is a written, signed instruction from an account holder to a bank to pay a named payee a stated amount from the drawer account. The payee presents the cheque to their own bank, which sends it for clearing, either physically or as an image, to the paying bank, which verifies the signature, the balance, and any stop instructions, and then settles the amount. Cheques were once the main instrument for business payments, and they are still used in some markets for high value, one off, or formal payments, and in some jurisdictions for government and legal settlements. Cheques are slow compared to electronic payments because clearing takes days, and they carry risks that electronic payments do not, such as forgery, alteration, loss in transit, and insufficient funds discovered only after presentation. Many countries have moved to cheque imaging, where a photograph of the cheque is cleared electronically, which shortens the cycle but does not remove the underlying paper risk. Some markets have retired cheques entirely, while others retain them for customers who cannot or will not use electronic channels. An analyst should never assume cheques are gone, and should always check the local market practice. From a systems perspective, cheques require controls for stop payments, for stale cheques that are presented after a validity period, for post dated cheques, and for returned cheques with reasons such as insufficient funds or signature mismatch. The return process is a key part of cheque operations, and a returned cheque can create a dispute between payer and payee that has no equivalent in an instant electronic transfer. When you document a cheque product or a migration away from cheques, capture the clearing timeline, the return codes, and the customer communication at each stage, because those details are what customers remember when something goes wrong. Take a cheque through its risks. A company issues a cheque for Rs 5,00,000 to a supplier on 1 March. The supplier presents it on 15 September, more than six months later. In India a cheque is valid for three months from its date of issue, so the bank returns it as stale, and the supplier must ask for a fresh cheque. A second case is simpler. The drawer discovers the goods were never delivered and issues a stop payment instruction before the cheque is presented. The bank honours the stop, the cheque is returned unpaid, and the dispute moves to the commercial negotiation, not the clearing system. A third case is forgery. A cheque for Rs 50,000 is altered to Rs 5,00,000 before presentation. The paying bank is expected to detect the alteration from the handwriting and the ink, and if it pays a forged cheque it may bear the loss. These are risks that electronic payments do not carry in the same form, which is why cheques survive mainly for formal, one off, or high value payments where a paper record matters. For an analyst, cheque work is mostly about the exceptions. The specification must list the validity period, the stop payment process and its deadline, the return codes for insufficient funds, signature mismatch, stale cheque, and post dated cheque, and the customer communication for each. When documenting a migration away from cheques, capture the clearing timeline first, because customers who are used to a three day cheque cycle will notice immediately if the electronic replacement takes longer, and capture the return process, because a returned cheque creates a dispute between payer and payee that an electronic payment would have prevented. A migration plan that only covers the happy path will fail on the first returned cheque.
A cheque is a written, signed instruction from an account holder to a bank to pay a named payee a stated amount from the drawer account. The payee presents the cheque to their own bank, which sends it for clearing, either physically or as an image, to the paying bank, which verifies the signature, the balance, and any stop instructions, and then settles the amount. Cheques were once the main instrument for business payments, and they are still used in some markets for high value, one off, or formal payments, and in some jurisdictions for government and legal settlements.
Cheques are slow compared to electronic payments because clearing takes days, and they carry risks that electronic payments do not, such as forgery, alteration, loss in transit, and insufficient funds discovered only after presentation. Many countries have moved to cheque imaging, where a photograph of the cheque is cleared electronically, which shortens the cycle but does not remove the underlying paper risk. Some markets have retired cheques entirely, while others retain them for customers who cannot or will not use electronic channels. An analyst should never assume cheques are gone, and should always check the local market practice.
From a systems perspective, cheques require controls for stop payments, for stale cheques that are presented after a validity period, for post dated cheques, and for returned cheques with reasons such as insufficient funds or signature mismatch. The return process is a key part of cheque operations, and a returned cheque can create a dispute between payer and payee that has no equivalent in an instant electronic transfer. When you document a cheque product or a migration away from cheques, capture the clearing timeline, the return codes, and the customer communication at each stage, because those details are what customers remember when something goes wrong.
Take a cheque through its risks. A company issues a cheque for Rs 5,00,000 to a supplier on 1 March. The supplier presents it on 15 September, more than six months later. In India a cheque is valid for three months from its date of issue, so the bank returns it as stale, and the supplier must ask for a fresh cheque. A second case is simpler. The drawer discovers the goods were never delivered and issues a stop payment instruction before the cheque is presented. The bank honours the stop, the cheque is returned unpaid, and the dispute moves to the commercial negotiation, not the clearing system. A third case is forgery. A cheque for Rs 50,000 is altered to Rs 5,00,000 before presentation. The paying bank is expected to detect the alteration from the handwriting and the ink, and if it pays a forged cheque it may bear the loss. These are risks that electronic payments do not carry in the same form, which is why cheques survive mainly for formal, one off, or high value payments where a paper record matters.
For an analyst, cheque work is mostly about the exceptions. The specification must list the validity period, the stop payment process and its deadline, the return codes for insufficient funds, signature mismatch, stale cheque, and post dated cheque, and the customer communication for each. When documenting a migration away from cheques, capture the clearing timeline first, because customers who are used to a three day cheque cycle will notice immediately if the electronic replacement takes longer, and capture the return process, because a returned cheque creates a dispute between payer and payee that an electronic payment would have prevented. A migration plan that only covers the happy path will fail on the first returned cheque.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.