The five decisions that actually matter
- Data boundary: can cheque images and extracted fields leave the bank’s network?
- Operational ownership: who patches, monitors, backs up, and upgrades the system?
- Latency and availability: what capture-to-result time is required, and what happens during a network outage?
- Model lifecycle: how do improvements reach the deployment, and how is a rollback handled?
- Evidence: what can the bank show an examiner for access, change, retention, and incident response?
Deployment models compared
| Model | Best for | Main trade-off |
|---|---|---|
| Cloud (multi-tenant) | Fast pilots, variable volume, minimal infrastructure | Data leaves the network; vendor operates the platform |
| Private cloud / VPC | Dedicated network and identity, regional residency | More setup and cost than multi-tenant; still vendor-operated |
| Hybrid | Capture or review on-prem; inference or archive in a controlled cloud | Two operational domains and a more complex data-flow review |
| On-premise | Data cannot leave the bank; customer-managed infrastructure | Customer owns hardware, patching, capacity, and DR |
| Air-gapped | No external network path; highest isolation | Manual update path, limited remote support, higher operating cost |
Security and compliance: location is not evidence
A common mistake is to treat “on-premise” as a compliance answer. It is not. On-premise can reduce the data boundary, but the bank still needs access control, encryption, logging, vulnerability management, change control, backup, and incident response. A cloud provider may have a stronger control set and independent reports; an on-premise deployment may give the bank more direct control. The right question is which control evidence you can obtain and operate.
- Request the current report, scope, auditor, and bridge letter where held.
- Ask for the data-flow diagram and the exact trust boundaries.
- Confirm who has production access, how it is logged, and how it is revoked.
- Confirm retention, deletion, backup, and legal hold for images, fields, and logs.
- Ask how vulnerabilities are triaged and how patches reach the deployment.
The security and compliance hub explains how to request the evidence package. The on-premise security page covers the architecture and control questions in more detail.
Latency, throughput, and the network boundary
Cloud OCR is usually fast enough for batch and review workflows, but capture-to-result time includes upload, queueing, inference, and response. On-premise can reduce the network leg and keep working during an internet outage, but it adds capacity planning and hardware failure modes. Measure the full path with your images and volume; do not compare a model’s inference time with an end-to-end workflow.
- Measure p50 and p95 capture-to-result, not only average.
- Test peak batch and concurrent review load.
- Test the behavior when the network or upstream scanner is unavailable.
- Include image upload time and queue wait in the target.
Model updates and support boundaries
A cheque OCR model is not static. Handwriting, layouts, and fraud patterns change. In a cloud deployment, updates can be continuous and invisible. In an on-premise deployment, the update path must be explicit: signed packages, a test environment, a rollout window, a rollback plan, and a supported-version policy. In an air-gapped deployment, the transfer process itself is a control.
Who approves an update?
The bank, the vendor, or a joint change board. Record the decision.
How is it rolled back?
Previous version retained, data/schema compatibility, tested rollback.
How long is the old version supported?
A defined support window, not “until further notice.”
What does support cover?
Model, integration, infrastructure, or only the application layer.
Total cost of ownership
Compare three years, not the first invoice. On-premise shifts cost from a subscription to hardware, GPU capacity, redundancy, disaster recovery, security tooling, operations staff, patching, and upgrade effort. Cloud shifts cost to usage and subscription but can reduce undifferentiated infrastructure work. The cheapest licence can be the most expensive deployment if the bank has to build a 24/7 GPU operations function.
- Compute: GPU/CPU, memory, storage, redundancy, and headroom for peak volume.
- Operations: patching, monitoring, backup, DR testing, capacity planning.
- Security: network segmentation, key management, logging, vulnerability management.
- Change: model updates, integration changes, regression testing, rollback.
- Support: escalation, named contacts, on-site/remote terms, renewal.
- Delay: procurement, infrastructure build, and security review time.
Decision matrix
| If this is true | Start with |
|---|---|
| Images cannot leave the bank network | On-premise or air-gapped; confirm the update and support model. |
| Regional residency but cloud operations are acceptable | Private cloud/VPC in the required region. |
| Capture must keep working during an internet outage | On-premise or hybrid capture with local queueing. |
| Fast pilot and variable volume | Cloud, with a clear data-handling boundary and exit plan. |
| Strict customer-managed keys or infrastructure | Private cloud or on-premise with documented key ownership. |
| No internal GPU operations capacity | Cloud or managed private cloud; do not underestimate on-prem ops. |
How Chequedb fits
Chequedb supports cloud, private-environment, and on-premise deployment paths. The on-premise path is documented with data flow, trust boundaries, controls, and due-diligence questions. The exact supported configuration, update process, SLA, and support boundary are confirmed for the deployment; do not infer them from the word “on-premise.”
For the implementation sequence, see the bank check OCR implementation guide. For the API contract, see the bank check OCR API docs.