A step-by-step guide to reading cheques inside India's Cheque Truncation System. Eight stages, the options at each one, exactly how each step connects to the next, real costs, and what breaks. Written for someone who has not built this before.
Verified September 2026Free · No signupOfficial sources only
BeginnerStart here. No prior knowledge assumed.
How to use this page
This page walks you through building one thing: turning a paper cheque into structured data a
banking system can act on, inside the rules of India's Cheque Truncation System.
Cheques are widely assumed to be dying. RBI still classifies paper clearing as a
System-Wide Important Payment System, which is the same category as the rails you
would never call obsolete. The volumes are falling and the values are not.
Watch out
The clock changed eleven months ago and most published guidance predates it. RBI circular RBI/2025-26/73 of 13 August 2025 introduced Continuous Clearing and Settlement on Realisation in CTS with effect from 4 October 2025. Cheques presented during the day now settle in hourly cycles with realisation by the evening of the same working day, replacing the two batch sessions that had governed cheque clearing for decades. Anything you read that describes a next-working-day cycle is describing the old system.
What a cheque image actually is
The first thing to be precise about: you are not reading a photograph of a cheque.
CTS defines exactly what a cheque image is, and a pipeline built for arbitrary document photos is
solving a different problem.
Image view
Specification
What it is for
Front, greyscale
Minimum 100 DPI, JFIF/JPEG, 8 bits per pixel (256 levels)
Handwriting — the amount, the payee, the signature
Front, black and white
Minimum 200 DPI, TIFF, CCITT G4
Contrast, archival, machine reading
Rear, black and white
Minimum 200 DPI, TIFF, CCITT G4
Endorsements and stamps
Note
The image is signed, and it is signed at the point of capture. It is mandatory for the presenting bank to digitally sign the image and data from the point of origin, and image and data remain secured by PKI through the whole cycle — capture system, presenting bank, clearing house, drawee bank. The system is built to be compliant with the IT Act, 2000. A pipeline that re-encodes, crops or enhances an image after capture breaks the signature, and therefore breaks the instrument. Any enhancement you do for your own reading happens on a copy.
Who you are changes the whole build:
You are
Your problem
The presenting bank
Capture, sign, extract, present into clearing. The full build.
The drawee bank
Verify against the account, match Positive Pay, pay or return — within the hour.
A corporate depositor
Reconciling what you banked against what cleared. No CTS integration at all.
A vendor
You sell into one of the first two. Their constraints are your specification.
What this is not:
Not an OCR benchmark. Accuracy on a public handwriting dataset predicts very
little here. Step 5.
Not a legacy project. The clearing cycle was rebuilt in 2025.
Not finished at extraction. The extraction has to agree with something the drawer
already declared. Step 6.
The whole journey, in one table
#
Step
In plain words
1
Establish which side you are on
Presenting, drawee, depositor or vendor.
2
Capture the image triple
To specification, signed at origin.
3
Read the MICR band
The easy, reliable, machine-printed part.
4
Read CAR and LAR
Amount in figures, amount in words. Handwritten.
5
Reconcile the two
The law already decided which one wins.
6
Match Positive Pay
Against what the drawer declared in advance.
7
Present, and watch the clock
Hourly cycles, same-day realisation.
8
Handle returns
Reasons, timelines, and the customer.
Note
Steps 5, 6 and 7 are where this differs from every other document-AI build, and they are the three that a vendor demonstration skips. Steps 2 to 4 are the part that looks like the product. An extraction engine that is excellent at 4 and silent on 5 and 6 has automated the easy half.
IntermediateBuild it. Pipelines, tools and working code.
Steps 1 to 3 — side, capture, MICR
Step 1 — Which side are you on?
Answer this before anything else, because the three builds share almost no code.
The presenting bank captures, signs and presents; its risk is a bad capture
entering clearing. The drawee bank receives an image and must decide to pay or
return; its risk is paying something it should have stopped, and its constraint is now time. A
corporate depositor has no CTS integration at all and a genuine reconciliation
problem: what was banked, what cleared, what bounced, and which invoice each one settles.
The corporate case is the largest addressable one and the least discussed, because
it needs no bank integration and no clearing membership — it is an internal reconciliation
product that happens to start with a cheque image.
Step 2 — Capture
Two rules that override anything a scanner vendor tells you. Capture to the CTS
specification, not to what your model prefers. And sign at origin, then never touch
the original again — every enhancement, deskew, crop or contrast adjustment happens on
a working copy.
What ruins a capture, in order of frequency: a rubber stamp overlapping the date, payee, amount or
signature; light-coloured ink; alterations, which CTS does not accept at all except for date
validation; and a cheque that is not CTS-2010 compliant, which has been out of clearing since
31 December 2018.
Step 3 — The MICR band
The MICR line is machine-printed in magnetic ink to a fixed specification, and it is the only field
on the cheque you should expect near-perfect accuracy on. It carries the cheque number, the MICR code
identifying the branch, the account number and the transaction code.
Note
Read the MICR band magnetically where you can, optically only as a fallback, and reconcile the two. Magnetic reading is immune to the things that defeat vision — a stamp across the band, a fold, a photocopy — and a disagreement between the magnetic and optical reads is one of the cheapest fraud signals available. It is also the only field where a mismatch means something unambiguous, which is why it is worth the extra hardware.
Steps 4 to 6 — read, reconcile, match
Steps 4 to 6 — Read, reconcile, match
Python — steps 4 to 6, read the amounts, reconcile them, match Positive Pay
from decimal import Decimal
# STEP 4. TWO AMOUNTS, BOTH HANDWRITTEN, ON THE SAME CHEQUE.
# CAR — Courtesy Amount Recognition — the amount in FIGURES
# LAR — Legal Amount Recognition — the amount in WORDS
# Read them independently. Never derive one from the other: an engine that
# parses the figures and "confirms" the words has one reading and a
# rationalisation, which is exactly the check you needed.
def read_amounts(grey_image):
car = read_car(grey_image) # {"value": Decimal, "confidence": float}
lar = read_lar(grey_image) # {"value": Decimal, "confidence": float}
assert car["source_region"] != lar["source_region"], "same region read twice"
return car, lar
# STEP 5. WHEN THEY DISAGREE. THE LAW ALREADY DECIDED THIS.
# Negotiable Instruments Act, 1881, section 18: where the amount is stated
# differently in figures and in words, THE AMOUNT IN WORDS is the amount
# ordered to be paid.
#
# So the words are not a check on the figures. The words ARE the amount, and
# the figures are the check. Most pipelines are built the other way round
# because figures are easier to read.
def resolve_amount(car, lar, policy):
if car["value"] == lar["value"]:
return {"amount": car["value"], "route": "auto", "agreed": True}
# A disagreement is not an error to resolve with a confidence score.
# It is a legal question with an answer, and a human should see it.
return {
"amount": lar["value"], # section 18: words govern
"route": "manual_review", # do not auto-pay a disagreement
"agreed": False,
"car": car["value"], "lar": lar["value"],
"why": "figures and words differ; words govern, review before paying",
}
# Confidence thresholds are a business decision, not a model setting.
def route(car, lar, policy):
if min(car["confidence"], lar["confidence"]) < policy["min_confidence"]:
return "manual_review"
if car["value"] >= policy["always_review_above"]:
return "manual_review" # value, not confidence
return "auto"
# STEP 6. POSITIVE PAY. THE DRAWER ALREADY TOLD THE BANK WHAT THIS SAYS.
# For cheques of Rs 50,000 and above the issuer submits the date, the payee
# and the amount to their bank in advance. CTS cross-checks the presented
# cheque against that declaration and flags any discrepancy to both banks.
def positive_pay_check(extracted, declared):
if declared is None:
return {"status": "no_declaration", "action": "follow_bank_policy"}
mismatches = [f for f in ("date", "payee", "amount")
if normalise(extracted[f]) != normalise(declared[f])]
return {"status": "match" if not mismatches else "mismatch",
"fields": mismatches,
# A payee mismatch is the alteration case Positive Pay exists for.
"action": "pay" if not mismatches else "flag_to_both_banks"}
# WHAT TO CHECK
# [ ] CAR and LAR read INDEPENDENTLY, from different regions, by paths that
# cannot see each other's output
# [ ] a disagreement routes to a human. Never auto-resolve by confidence
# [ ] where you must act on one, act on the WORDS. Section 18 is not a
# preference
# [ ] normalise before comparing payee names, or Positive Pay flags every
# cheque over a full stop
# [ ] a value threshold for manual review, independent of confidence. A
# confident wrong reading on a large cheque is the expensive failure
# [ ] reconcile magnetic and optical MICR reads and treat disagreement as a
# fraud signal, not a retry
THE finding:the extraction is the easy half. The hard half is that your
reading has to agree with something the drawer already declared — and now inside an
hour.
Under the Positive Pay System, the issuer of a cheque submits the date, the payee
name and the amount to their own bank in advance, through SMS, the mobile app, internet banking or an
ATM. CTS cross-checks the presented instrument against that declaration and flags any discrepancy to
both the drawee and the presenting bank. Banks enable it for cheques of ₹50,000 and
above, and may make it mandatory above ₹5 lakh.
That changes what accuracy means. Your engine is not trying to be right in the abstract; it
is trying to agree with a specific prior statement. A reading that is objectively correct and
disagrees with the declaration still stops the cheque — and it should.
Watch out
The comparison is where this goes wrong, not the reading.M/s Sharma Traders against Sharma Traders Pvt Ltd. A trailing full stop. An initial with and without a space. Normalise aggressively before comparing, or Positive Pay will flag a large share of perfectly good cheques — and a system that flags everything is a system a bank switches off. The payee field is where the value is, because payee alteration is precisely the fraud Positive Pay was introduced to catch.
Steps 7 and 8 — present, and returns
Step 7 — Present, and the clock that changed
Until October 2025, cheque clearing ran in two batch sessions and the beneficiary typically waited
until the next working day. RBI circular RBI/2025-26/73 of 13 August 2025 replaced
that with continuous clearing and settlement on realisation, effective
4 October 2025.
Then
Now
Two fixed batch sessions
Continuous presentation through the working day
Settlement at session close
Hourly settlement on realisation
Credit typically next working day
Credit the same working day once the paying bank confirms
A confirmation window measured in hours
A confirmation window measured in the hour, bounded by the Item Expiry Time
Python — steps 7 and 8, the hourly cycle and the return path
from datetime import datetime, timedelta
# STEP 7. CONTINUOUS CLEARING. THE DEADLINE IS NOW PER ITEM, NOT PER DAY.
# Before 4 October 2025 an item joined a batch and the batch had a deadline.
# Now each item has its own confirmation window, bounded by the Item Expiry
# Time. A review that used to "make today's cut-off" now has to make an hour.
def review_deadline(presented_at, cutoffs):
"""When this specific item stops being yours to decide."""
return min(presented_at + cutoffs["confirmation_window"],
cutoffs["item_expiry_time_for"](presented_at))
def route_with_clock(item, policy, staffing):
decision = route(item["car"], item["lar"], policy) # auto | manual_review
if decision == "auto":
return {"action": "auto", "by": None}
due = review_deadline(item["presented_at"], policy["cutoffs"])
# The question is not "is a human available" but "is one available BEFORE
# this item expires". A queue drained at day end answers the first.
if not staffing.reviewer_available_before(due):
# Do not let it expire silently. An expiry is a return the customer
# did not earn and nobody decided.
return {"action": "escalate_now", "due_ist": due, "why": "no reviewer in window"}
return {"action": "manual_review", "due_ist": due}
# STEP 8. RETURNS.
def handle_return(item, reason_code, store):
# Keep the evidence WITH the return. The dispute arrives later and the
# question is always what the instrument actually said.
store.attach(item["id"], images=item["image_triple"],
extraction=item["extraction"], positive_pay=item["pp_result"])
return {
"reason_code": reason_code,
# Plain language reaches the customer; the code reaches the system.
"customer_message": PLAIN[reason_code],
"at_ist": now_ist(),
}
def return_rate_by_reason(window, baseline):
"""A rising 'signature differs' rate is a capture or model problem wearing
a customer-behaviour costume. Nothing else in the reporting shows it."""
rates = group(window, "reason_code")
return {r: {"rate": v, "drifted": v > baseline[r] * 1.5} for r, v in rates.items()}
# WHAT TO CHECK
# [ ] compute the deadline PER ITEM, not per session. The batch mental model
# is the single biggest carry-over risk from the old cycle
# [ ] alert when no reviewer is available before an item expires, rather
# than discovering it in the return file
# [ ] never let an item expire silently into a return. That is a decision
# nobody made, reaching a customer who did not earn it
# [ ] attach the images and the extraction to every return. The dispute is
# later and the evidence is not reconstructable
# [ ] track return rate BY REASON against a baseline, and treat a jump in a
# capture-sensitive reason as a pipeline alert
# [ ] every timestamp in IST against the clearing calendar, never a UTC day
Watch out
For a drawee bank this is the change that matters and it is an operations change, not a technology one. The decision to pay or return used to have most of a day behind it, with a queue of exceptions worked through by people. It now has to be made inside an hourly cycle. Anything that routes to manual review needs a reviewer available during clearing hours, not a queue drained at four o'clock. A pipeline that auto-approves 95% and leaves 5% for a team that works batch-style will miss the window on the 5% that mattered enough to flag.
Step 8 — Returns
A returned cheque is not an error state in your pipeline — it is a normal outcome with a
reason code, a customer on the other end, and in some cases legal consequences under the Negotiable
Instruments Act.
Three things to build properly. Carry the reason through to the customer in plain
language: insufficient funds, signature differs, alteration requires
drawer confirmation, Positive Pay mismatch. Second, keep the image and the
extraction against the return, because the dispute arrives later and the question is always
what the instrument actually said. Third, track your return rate by reason — a
rising signature differs rate is a model or capture problem wearing a customer-behaviour
costume, and nothing else in your reporting will tell you that.
What it costs
Cheque reading — what it costs
Verified September 2026
Capture hardwaredirect
Scanners meeting the CTS image specification, with magnetic MICR reading rather than optical alone. The magnetic read is worth the hardware: it is immune to stamps, folds and photocopies, and disagreement with the optical read is a free fraud signal.
Extractiondirect
Per document or a licence. Cheaper than it looks and less decisive than it is sold as — the MICR band is reliable, and CAR and LAR are the only genuinely hard fields.
Manual review capacitydirect
The line that decides whether the system works. Since continuous clearing, reviewers must be available during clearing hours rather than draining a queue at day end. This is a staffing model, not a headcount.
Positive Pay integrationdirect
Matching against the drawer's declaration, with the normalisation work that stops it flagging good cheques. Budget the normalisation, not the match — the match is trivial and the normalisation is the product.
Archivaldirect
Signed images retained to specification, retrievable years later when a dispute arrives. Storage is cheap; retrievability under a legal request is the requirement.
Getting it wrongindirect
Paying an altered cheque is a loss the bank absorbs and a customer relationship it does not. On the other side, a false-positive rate high enough to be annoying gets the system switched off, which is the more common failure and the harder one to recover from.
Where to buy these: Payments Reconciliation Build Sheet names every tool with its unit cost. Getting Access covers which ones you can sign up for today, which need a sales call, and which are licensed.
Note
The number to compute first: what share of cheques by VALUE currently needs a human, and could a human reach them inside an hour? Not the volume share — the value share. That single figure tells you whether continuous clearing is a timing problem you can staff or an architecture problem you cannot, and it is answerable from last quarter's data in an afternoon.
AdvancedShip it. Failure modes, thresholds and evidence.
Three versions you could build
Reconcile what you banked
Build: photograph or scan on deposit → read MICR and CAR → match against
your receivables ledger → reconcile against the bank statement when it clears.
You get: the corporate depositor product. No CTS integration, no clearing
membership, no regulator — and it solves a real reconciliation problem that most
finance teams still do by hand.
Presenting-bank capture
Build: capture to the CTS image specification → sign at origin →
magnetic MICR with optical reconciliation → independent CAR and LAR → disagreement routes to
a human → present into the continuous cycle.
Trade: real hardware and real clearing-house integration. The enhancement
rule bites here — the signed original is the instrument, and everything you do to read
it happens on a copy.
Drawee-bank decisioning
Build: the above, plus Positive Pay matching with proper normalisation, signature
verification against specimens, account-level checks, a review queue staffed during clearing
hours, and return handling with reasons carried through to the customer.
It breaks when: the review queue is designed for the old batch rhythm. The
technology was never the constraint; the hour is.
Note
If you take one thing from this page: read the amount in words independently, and when it disagrees with the figures, the words govern. Section 18 of the Negotiable Instruments Act settled that in 1881. Most pipelines treat the figures as the answer and the words as a check, because figures are easier to read — which is exactly backwards.
What goes wrong
What goes wrong
Why
Fix
Signature broken by enhancement
Deskew or contrast applied to the original.
Sign at origin. Enhance a copy.
LAR derived from CAR
The words are hard; the figures are easy.
Independent reads, or you have one reading and a rationalisation.
Disagreement auto-resolved by confidence
Treated as a model problem.
It is a legal question. Words govern; a human sees it.
Positive Pay flags good cheques
Payee compared without normalisation.
Normalise aggressively. A system that flags everything gets switched off.
Confident wrong reading on a large cheque
Routing by confidence only.
A value threshold as well, independent of confidence.
MICR misread on a stamped band
Optical reading only.
Magnetic read; treat disagreement as a fraud signal.
Review queue misses the cycle
Designed for two batch sessions.
Reviewers available during clearing hours.
Non-CTS-2010 cheque in the pipeline
Still valid as an instrument, not in clearing.
Detect and route to another collection mode.
Alteration accepted
Treated as a low-confidence read.
CTS does not accept alterations except date validation. Return it.
Return reason not carried to the customer
Reason code stays in the system.
Plain language, and keep the image against the return.
Rising "signature differs" rate unexplained
Read as customer behaviour.
It is usually capture or model drift. Track returns by reason.
This page is a guide, not a specification. CTS participation is governed by RBI circulars and NPCI procedural documents that are revised regularly, and the clearing cycle itself changed in October 2025. Nothing here is legal advice. Build from the current NPCI specification your clearing membership gives you, and confirm every image and timing parameter against it.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
officialRBI circular RBI/2025-26/73 dated 13 August 2025 — Continuous Clearing and Settlement on Realisation in CTS — the replacement of two batch clearing sessions with continuous presentation and hourly settlement from 4 October 2025, same-working-day realisation once the paying bank confirms, and the Item Expiry Time that bounds the confirmation window. www.rbi.org.in
officialNPCI — Cheque Truncation System documentation and FAQs — CTS as an image-based clearing system operated by NPCI under the amended Negotiable Instruments Act 1881, RBI’s classification of paper clearing as a System-Wide Important Payment System, retention of the physical instrument at the presenting bank, and the clearing-house interface behaviour including duplicate detection. www.npci.org.in
officialRBI / NPCI CTS image and interface specification — the three image views per instrument — front greyscale at a minimum of 100 DPI in JFIF/JPEG at 8 bits per pixel, and front and rear black and white at a minimum of 200 DPI in TIFF with CCITT G4 compression — the mandatory digital signature applied by the presenting bank from the point of origin, PKI protection across the whole cycle, and compliance with the IT Act, 2000. www.npci.org.in
officialRBI — CTS-2010 Standard for cheque forms — the security features required of a compliant instrument, including micro-lettering, bleeding ink, security thread and the UV band over the legal amount, courtesy amount, signature and beneficiary fields; and the discontinuation of separate clearing for non-CTS-2010 instruments from 31 December 2018. www.rbi.org.in
officialRBI — Positive Pay System for CTS — the requirement that banks enable Positive Pay for cheques of ₹50,000 and above, with discretion to mandate it above ₹5 lakh; the drawer’s advance submission of date, payee and amount through SMS, mobile app, internet banking or ATM; and the cross-check by CTS with discrepancies flagged to both the drawee and presenting banks. www.rbi.org.in
officialNegotiable Instruments Act, 1881 — section 18 — that where the amount is stated differently in figures and in words, the amount stated in words is the amount ordered to be paid. Also the basis, as amended, for truncation replacing the physical instrument with its image and MICR data. www.indiacode.nic.in
officialRBI guidance to customers on cheque preparation — the use of image-friendly dark ink, care with rubber stamps so they do not overshadow the date, payee, amount or signature, and that cheques carrying alterations other than date validation are not accepted under CTS. www.rbi.org.in
industryImplementation commentary on CTS capture and clearing — the practitioner read on capture-system architecture, magnetic versus optical MICR reading, and operational staffing under the continuous cycle. Directional; confirm every specification against the notified NPCI document before building to it.
Checked September 2026. The clearing cycle changed on 4 October 2025 — treat any guidance describing next-working-day clearing as out of date, including anything published before then.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.