Deployment architecture

On-Premise Cheque Processing: Security and Architecture

A bank-facing view of how on-premise cheque processing should be scoped: the data flow, the trust boundaries, the controls to verify, and the questions to ask before a security sign-off. The goal is not to claim compliance from a deployment model; it is to make the control surface explicit.

Customer-controlled data Audit-friendly evidence Controlled updates

Reference data flow

Customer-controlled boundary

Capture

Scanner, mobile, or API intake inside the customer network. Review the scanner SDK integration guide to define the capture handoff at this boundary.

Queue

Images and metadata land in a controlled ingestion queue.

Extract

OCR/HTR and MICR models run locally or in the private VPC.

Validate

Field rules, CAR/LAR agreement, duplicates, and date checks.

Review

Exceptions route to authorized reviewers with the source image.

Archive

Approved records, evidence, and audit events are retained by policy.

Identity plane: SSO, roles, maker-checker, and privileged-access review.
Evidence plane: append-only audit events, model/rule versions, reviewer decisions, and exports.
Update plane: signed, versioned model and rule packages with rollback.

Deployment models

ModelBest fitTrade-off to confirm
Air-gappedStrict data-sovereignty or no-egress requirementsUpdate logistics, support access, and model refresh cadence
Private VPCBank-controlled cloud tenancy with private networkingSubnet/egress design, key management, and shared-responsibility split
HybridImages stay local; some management or updates are centralizedExactly what crosses the boundary, and how it is logged and protected

Controls to verify

These are the control areas a bank security review should see evidence for. The list is not a certification claim; it is a checklist for the conversation.

Network boundary

Segmentation, private subnets, restricted egress, and explicit allow-lists. Confirm whether any outbound telemetry or support tunnel exists.

Identity and access

SSO/OIDC or SAML, least-privilege roles, maker-checker separation, session controls, and joiner/mover/leaver processes.

Encryption

TLS in transit, encryption at rest, customer-managed keys where required, and a documented key-rotation and recovery process.

Secrets

No secrets in images or source control; a vault or KMS-backed secret store; rotation and break-glass procedures.

Audit logging

Append-only or tamper-evident events for access, edits, approvals, exports, model/rule changes, and administrative actions.

Retention and deletion

Configurable retention, legal hold, secure deletion, and evidence that deletion actually happened across copies and backups.

Backup and recovery

RPO/RTO targets, restore testing, encrypted backups, and a recovery plan that does not depend on a single site.

Model updates

Signed, versioned packages; customer-approved change windows; rollback; and a record of which model version produced each result.

Monitoring

Health, latency, error rate, queue depth, review backlog, and security-event monitoring with an agreed escalation path.

What on-prem does not prove

  • • It does not automatically make the deployment SOC 2, ISO 27001, or PCI compliant.
  • • It does not remove the bank’s own obligations for access, retention, or supervision.
  • • It does not guarantee that no telemetry, support access, or model call leaves the network.
  • • It does not replace a security review, penetration test, or contractual controls.

Ask for the architecture and evidence, not a one-line “on-premise” claim.

Due diligence questions

  • Which components run inside our network, and which (if any) call a vendor service?
  • What data leaves the network for telemetry, support, licensing, or model updates?
  • How are images, extracted fields, signatures, and audit logs encrypted at rest?
  • Who can access the system, and how is privileged access approved and reviewed?
  • How are model and rule updates signed, tested, approved, and rolled back?
  • What is the retention period, and how is deletion verified across backups?
  • What evidence is available for SOC 2, ISO 27001, or a bank security review?
  • What are the RPO/RTO and the last successful restore-test date?
  • How are vulnerabilities tracked, prioritized, and patched?
  • What happens during an incident, and who communicates with the bank?

Evaluate the deployment, not just the demo

Bring your security questions, representative cheque images, and target workflow to a scoped pilot. The review should cover the data flow, the review path, the audit evidence, and the update process before production rollout.

Discuss an on-prem pilot See the OCR benchmark

Related pages

On-premise cheque processingSecurity & compliance hubHandwritten OCR benchmarkCheque management system for banksBank check OCR API

On-premise cheque security: common questions

What does on-premise cheque processing mean?

It means the cheque processing software, models, and data run in an environment the customer controls, such as a bank data centre, a private VPC, or an air-gapped network. The exact boundary depends on the deployment; confirm what leaves the network, what is logged, and how updates are delivered.

Does on-premise deployment make a system compliant?

No. Hosting software inside your network does not by itself establish SOC 2, ISO 27001, PCI, or any regulatory compliance. Compliance depends on the full control environment, evidence, policies, audit scope, and the customer’s own obligations. Ask for the current control set and reports rather than inferring certification from the deployment model.

How are models updated in an air-gapped deployment?

Typically through a signed, versioned update package that is reviewed and installed by the customer. The exact process, signature verification, rollback path, and approval workflow should be documented in the deployment plan. Confirm that model updates cannot bypass the customer’s change control.

What data should be logged?

At minimum: who accessed which cheque, what field was viewed or changed, which rule or model version applied, what decision was made, and when. Logs should be tamper-evident or append-only, retained according to policy, and exportable for audit or legal review.

Can cheque images leave the network?

That is a deployment decision. A fully on-premise or air-gapped deployment is designed so images and extracted fields remain inside the customer-controlled environment. If telemetry, support access, or cloud model calls are enabled, document exactly what leaves, why, and how it is protected.

What should a bank ask before signing off?

Ask for the architecture, data-flow diagram, subprocessors, encryption and key-management model, identity and access controls, logging and retention, backup and disaster recovery, vulnerability management, model-update process, incident response, and the evidence available for procurement review.

This page describes control areas to evaluate. It is not a certification, a security guarantee, or legal advice. The current control set, evidence, and contractual commitments are confirmed during procurement.