A remote deposit capture (RDC) system that takes a photograph of a check and processes it through an automated pipeline, ultimately producing a valid X9.100-187 Image Cash Letter file for clearing against a receiving bank.

The system demonstrates the full lifecycle of financial check processing: image capture, quality validation, MICR line recognition, amount verification, duplicate detection, cash letter assembly, and submission to a receiving institution simulator. Each stage runs as an independent worker consuming from a message queue, allowing per-stage scaling and retry semantics.

All check images are synthetically generated — no real financial data is used anywhere in the project.

The system uses an event-driven microservice architecture with SQS queues connecting independent processing stages:

React Frontend (Vite + TypeScript)
    |
    v
Gin REST API  (Go)
    |           \
    v            v
PostgreSQL    AWS S3 (KMS-encrypted images)
    ^
    |
SQS Queues → Stage Workers (IQA → MICR → CAR/LAR → Dupe → Cash Letter)
    |
    v
ICL Receiver (simulated clearing bank)
                

Event-driven stages. Each processing stage (image quality, MICR recognition, amount verification, etc.) runs as an independent worker process consuming from its own SQS queue. When a stage completes, it publishes to the next queue in the pipeline. This decoupling means stages can be scaled independently, retried without affecting other stages, and monitored individually via dead-letter queues.

Single worker binary. All stage workers compile into one Go binary (icl-worker) with subcommands per stage (e.g., icl-worker iqa, icl-worker micr). This simplifies the container image while still allowing Kubernetes to scale each stage independently by running different subcommands in separate pods.

LocalStack for development. The same code path targets LocalStack (local) and real AWS (production) via environment variables only. S3, SQS, and KMS all run locally in Docker Compose with zero AWS costs during development.

Each check item progresses through a defined state machine. Every transition is recorded as an immutable, hash-chained audit entry:

captured → iqa_passed → micr_read → amount_read → dupe_checked → bundled → sent → posted | returned | rejected
                

Items that fail any stage are routed to an exception queue for manual review. The exception handling UI lets operators inspect failed items, view failure reasons, and manually key corrected values.

The REST API manages deposits, items, exceptions, and cash letters:

All responses follow the standard envelope: { "result": bool, "data": T, "error": string }.

Every state transition for every check item is recorded in an append-only item_states table with cryptographic hash chaining:

hash = SHA256(prev_hash || item_id || state || payload || timestamp)

Each record links to the previous via its hash, forming an immutable chain. The verification endpoint walks the entire chain for an item and recomputes hashes to detect any tampering. If a single record has been modified, every subsequent hash will fail verification.

This is a critical compliance feature in financial systems — regulators require provable audit trails for every check that enters the clearing process. The hash chain provides cryptographic proof that no record has been altered after the fact.

The frontend includes an audit trail viewer that displays the chain for any item, with visual indicators for verified and broken links.

The IQA stage validates check images using pure Go image processing — no OpenCV or external dependencies. Five tests run against each image:

Results are stored with measured values and pass/fail thresholds. Failed items are routed to the exception queue with specific failure reasons, so operators know exactly what went wrong.

PostgreSQL with versioned migrations managed by golang-migrate. Seven migrations define the schema:

Local development uses Docker Compose with PostgreSQL and LocalStack (S3, SQS, KMS). No AWS account needed during development.

AWS resources are defined in Terraform:

• S3 bucket with versioning, object lock (governance mode), and 90-day Glacier lifecycle
• KMS customer-managed key for envelope encryption of check images
• SQS queues per processing stage, each with its own dead-letter queue
• IAM roles with least-privilege access policies

Production deployment targets Kubernetes (k3s) on a DigitalOcean droplet with Traefik ingress and Let's Encrypt TLS.

Language

Go

Web Framework

Gin

Database

PostgreSQL

Message Queue

AWS SQS (LocalStack in dev)

Object Storage

AWS S3 with KMS encryption

ICL Standard

moov-io/imagecashletter (X9.100-187)

Routing Validation

moov-io/fed (ABA routing numbers)

Migrations

golang-migrate

Frontend

React 19 + TypeScript + Vite

Linting

Oxlint

Infrastructure

Docker Compose, Terraform, Kubernetes (k3s)

Image Processing

Pure Go (no OpenCV dependencies)