ATM Cheque Deposit Orchestration: From SCPM to Core Banking

ATM cheque deposit orchestration sits between terminal capture and bank processing. The hardware accepts and images the paper. ChequeDB interprets that evidence, applies workflow rules, coordinates host decisions, records each transition, and sends approved items towards posting, clearing, reconciliation, and archive.

That distinction matters with NCR Scalable Cheque Processing Module (SCPM) deployments. SCPM handles physical custody: bunch separation, front and rear imaging, MICR acquisition, escrow, return, endorsement, and secure storage. It does not decide whether a cheque should be credited, reviewed, returned, cleared, or reversed.

SCPM is NCR hardware, not ChequeDB hardware. ChequeDB supports the image-intelligence and deposit-orchestration integration above it. The bank must confirm procurement, lifecycle, maintenance and current vendor support for the exact NCR configuration.

ChequeDB supports this architecture through a supported integration with the NCR application layer and the bank host. It does not bypass NCR XFS, APTRA, Advance NDC, NDC Enterprise, or other approved device software to issue undocumented hardware commands. The supported NCR SCPM integration model keeps those responsibilities separate.

The first article in this series explains what NCR SCPM hardware does versus what cheque processing software must do. The second follows the Bunch Cheque Acceptance workflow from escrow to reconciliation.

One deposit spans two control planes

An ATM deposit looks like one customer action. Operationally, it crosses two control planes.

The device control plane owns the physical item. NCR hardware, its XFS service provider, and the supported ATM application execute media commands. They open the input path, separate the bunch, capture images and MICR observations, hold items in escrow, present returned items, endorse accepted items, and move paper into a bin.

The deposit control plane owns the transaction. ChequeDB accepts the supported image and item evidence, assigns durable identities, runs OCR and ICR extraction, applies validation and risk rules, coordinates customer and bank-host decisions, routes exceptions, and creates a reconciliation record. It can then drive posting and clearing workflows through supported bank integrations.

The boundary is deliberate:

This avoids a dangerous design error: treating possession of a cheque image as proof that the physical item was captured, or treating a host approval as proof that core posting succeeded.

Reference architecture: device, ChequeDB, and bank host

The transaction should move through explicit integration contracts.

1. The ATM application creates a terminal transaction reference before accepting paper.
2. NCR Bunch Cheque Acceptance separates and images each item while the physical bunch remains under device control.
3. The supported device/application layer exposes per-item images, MICR observations, sequence, and current custody state.
4. ChequeDB creates a deposit record and one item record for every cheque.
5. The cheque data extraction workflow returns structured fields, field confidence, image-quality results, and validation findings. It does not reduce the item to one opaque score.
6. ChequeDB applies bank policy and calls the bank host for customer, account, limit, duplicate, and posting decisions.
7. The result is translated into a supported physical disposition request: capture, return, or hold under a documented exception path.
8. ChequeDB records physical completion separately from host approval.
9. Accepted items proceed to posting, clearing, reconciliation, and archive adapters.

The bank can deploy ChequeDB on-premises or behind the bank's own integration boundary. The bank check OCR API can provide the structured image-processing contract, while the orchestration layer tracks the longer-lived deposit lifecycle.

Bunch Cheque Acceptance requires two levels of state

Bunch Cheque Acceptance cannot be modelled as one boolean outcome. A customer may insert ten cheques and receive a mixed result. Seven may be accepted, one may need a corrected amount, one may be rejected by policy, and one may have an unreadable image.

The transaction therefore needs both a bunch-level state and an independent item-level state.

Transaction-level state

A practical transaction state model includes:

CREATED
INPUT_ENABLED
BUNCH_PRESENTED
ITEMS_CAPTURED
DECISION_PENDING
CUSTOMER_CONFIRMATION_PENDING
HOST_PENDING
DISPOSITION_PENDING
PHYSICAL_COMPLETION_PENDING
POSTING_PENDING
CLEARING_PENDING
COMPLETED
COMPLETED_WITH_EXCEPTIONS
REVERSAL_PENDING
RECOVERY_REQUIRED
CANCELLED

The bunch should advance only when every known item has reached a state compatible with that transition. For example, the transaction cannot become COMPLETED while one item remains PHYSICAL_CAPTURE_UNKNOWN or POSTING_UNKNOWN.

Item-level state

Each cheque should have its own lifecycle:

OBSERVED
IMAGED
EVIDENCE_BOUND
EXTRACTED
VALIDATED
REVIEW_REQUIRED
APPROVED
REJECTED
RETURN_REQUESTED
RETURN_PRESENTED
RETURN_TAKEN
RETURN_RETRACTED
CAPTURE_REQUESTED
CAPTURED
ENDORSED
POSTING_PENDING
POSTED
CLEARING_SUBMITTED
CLEARING_ACCEPTED
CLEARING_REJECTED
ARCHIVED
RECOVERY_REQUIRED

These are business states, not a replacement for NCR device states. The integration maps supported device events into ChequeDB's durable record. An NCR event that reports an item in escrow, for example, updates custody evidence. ChequeDB does not pretend it moved the paper itself.

Identity and idempotency must start before OCR

Retries are normal in ATM transactions. A network response can be lost after the host commits. The terminal can restart while a cheque remains in escrow. An archive service can accept an image and time out before returning its identifier.

Every call therefore needs an idempotency key derived from stable transaction and item identities, not from a request timestamp.

A useful identity set is:

The same logical operation must reuse the same key after a timeout. A retry with a new key can create a second credit. A retry with the original key lets the receiver return the stored result or continue the existing operation.

Idempotency also applies to image processing. If the same front and rear images are submitted again for the same item_id, ChequeDB should return the existing extraction version unless the caller explicitly requests a new model run. The record retains both versions when reprocessing is intentional.

The transaction needs a commit protocol

Host approval, physical capture, core posting, and clearing submission do not happen atomically. Treating them as one step creates unreconciled deposits when any system fails between calls.

A safe orchestration sequence separates intent from completion:

1. Prepare the deposit. ChequeDB validates the evidence and asks the host whether the item is eligible.
2. Record the decision. The host response is stored with its reference and policy reasons.
3. Request physical disposition. The supported NCR application receives a capture or return instruction for each item.
4. Confirm physical outcome. Device events confirm captured, returned, retracted, or unknown custody.
5. Post the financial transaction. The core adapter posts only according to the bank's chosen policy and known custody state.
6. Submit for clearing. The accepted image and codeline package enters the clearing workflow.
7. Reconcile and archive. Every system reference and evidence hash is joined to the final item record.

Some banks will reserve or memo-post before physical capture and final-post afterwards. Others will post only after capture. ChequeDB should encode the selected policy explicitly. It should not hide the timing inside integration code.

Timeouts produce unknown outcomes, not automatic failures

A timeout says that the caller did not receive a response. It does not prove that the remote action failed.

This is most important around host posting. If the core accepts a debit or credit and the response is lost, immediately sending a compensating reversal can be as wrong as retrying with a new identity. The orchestrator should first query the original operation by host_request_id.

The timeout policy should distinguish four cases:

If a supported escrow time limit is approaching, the ATM policy must choose a documented physical fallback. That may be returning the item, capturing it to a controlled exception bin, or taking the terminal out of service. ChequeDB can coordinate the business workflow around that decision. NCR software remains responsible for executing the media command.

Reversals are compensating transactions

A reversal should refer to the original posting and explain why compensation is required. It is not a deletion.

Typical reversal triggers include:

• the host posted an item but the device later confirmed that it was returned to the customer;
• physical capture remained unknown beyond the bank's reconciliation window;
• an accepted item failed a mandatory downstream control before clearing;
• a clearing rejection requires the provisional customer credit to be removed under bank policy.

Each reversal record should contain the original host reference, reversal reference, reason code, item identity, initiating actor, timestamps, and evidence links. The original decision remains visible. This supports the cheque management and audit workflow instead of rewriting history.

Item-level decisions preserve customer and bank intent

The orchestration layer should keep four values separate for each cheque:

1. the machine-extracted value;
2. any customer correction;
3. the bank-host value or decision;
4. the final posted and clearing value.

For example, OCR may extract an amount of 12,500 with low confidence. The customer may confirm 17,500. A validation rule may flag disagreement between numeric and written amounts. The host may then require manual review rather than approve or reject immediately.

The item should not inherit the decision of the bunch. Nor should one exception force accepted items into an ambiguous state. ChequeDB can return a per-item decision matrix:

The exact ability to capture selected items and return others depends on the quoted NCR hardware/software configuration. It must be confirmed through supported product documentation and acceptance testing. ChequeDB should never claim a physical option that the device stack cannot execute.

Evidence correlation closes the custody gap

A deposit record is defensible only when the electronic decision can be matched to the physical item.

For every cheque, ChequeDB should bind:

• original front and rear image hashes;
• optional UV image hashes where the supported module provides them;
• MICR observation and parsed control-line fields;
• image-quality and field-level extraction results;
• model and ruleset versions;
• customer edits and confirmations;
• host requests, responses, and references;
• NCR transaction, item-sequence, and device-journal references;
• physical disposition events;
• endorsement evidence when available;
• core posting and reversal references;
• clearing and archive references.

The manifest should be append-only. Later events extend the history rather than altering earlier evidence. This makes it possible to answer operational questions such as: Was the customer credited? Was the paper captured? Which image entered clearing? Was a returned item later retracted? Did the archive acknowledge the same bytes?

Exception review is part of the transaction, not a side queue

Manual review must preserve the same identities and state transitions as automated processing. An operator can correct extracted data, approve a flagged item, reject it, or request more evidence. Every action needs a reason and actor.

The review queue should show the evidence required for the decision:

• front and rear images with field regions;
• MICR control line and confidence;
• numeric and written amount comparison;
• date, payee, crossing, signature-presence, and image-quality findings;
• duplicate candidates;
• customer edits;
• current physical custody;
• host and posting status.

Review cannot safely wait for hours while paper remains in an ATM escrow. Real-time exceptions need a bounded terminal policy. Deferred review generally requires the item to be captured into a controlled exception state before the customer session ends. The bank decides that policy; the supported NCR layer performs the physical action; ChequeDB carries the review and reconciliation workflow forward.

Recovery starts by reconciling facts, not replaying commands

After a terminal, network, or service restart, the orchestrator should not blindly replay the last command. It should reconstruct the transaction from independent evidence.

A recovery worker should compare:

1. ChequeDB transaction and item states;
2. NCR application journal and current device/custody status;
3. host authorisation and posting status;
4. clearing submission status;
5. archive acknowledgements.

It can then choose a controlled action:

• resume a pending idempotent call;
• mark the item captured and continue posting;
• mark the item returned and cancel or reverse the financial action;
• create an exception when physical custody remains unknown;
• prevent new deposits until bin and journal reconciliation is complete.

The system should expose RECOVERY_REQUIRED as a first-class state. Hiding uncertainty behind FAILED removes the information operations teams need to resolve it.

Reconciliation proves that the workflow closed

Reconciliation should compare counts and values across every boundary:

A deposit can be customer-complete while still operationally open. For example, customer credit may be posted, but clearing acknowledgement or archive replication may remain pending. ChequeDB should preserve that distinction and raise ageing exceptions without losing the customer-facing result.

What ChequeDB returns

The output is more than parsing and more than a risk score. A production response can include:

• structured MICR, amount, date, payee, and other extracted fields;
• field confidence and image-quality findings;
• validation, duplicate, and policy reason codes;
• per-item accept, reject, correct, or review recommendations;
• host and core-banking references;
• requested and confirmed physical disposition;
• posting, reversal, clearing, archive, and reconciliation states;
• a complete audit-friendly processing history.

This is the difference between reading a cheque and operating a cheque deposit service.

Design the acceptance test around failures

A successful demonstration proves only the happy path. A bank should test the exact NCR configuration, supported ChequeDB integration, host adapter, and real cheque corpus under failure.

The acceptance plan should include mixed-decision bunches, duplicate host calls, delayed OCR, lost responses, host timeouts, power interruption in escrow, capture confirmation loss, customer cancellation, return-not-taken, endorsement failure, nearly full bins, clearing rejection, and archive unavailability.

For each test, verify the physical item, device journal, ChequeDB item state, host posting, clearing state, and archive evidence. The system passes only when those records reconcile without duplicate credit or lost custody.