Reconciliation System

CDM Switch

Turning a fleet of physical cash deposit machines into one centrally monitored, centrally managed network

A switch platform built to connect a bank's entire fleet of Cash Deposit Machines (CDMs) into a single system — giving banks real-time visibility into machine health, centralized control over on-screen content, and a unified, auditable record of every deposit transaction across every branch.

The system was built to address a problem that grows with every machine a bank deploys: a CDM isn't just a device, it's a small, physically distributed piece of infrastructure — and a fleet of them, spread across branches, is only manageable if someone can see all of it, at once, from one place.

Key metrics

Real-time monitoring across an entire CDM fleet — door, sentry, vault, printer, and receipt status per machine
Open APIs and webhooks for system event notifications and third-party integration
Centralized transaction logging with automated photo extraction mapped to each transaction
Remote content management — background images, advertisements, and theming pushed to all machines from one dashboard
End-to-end encryption, and multilevel role-based access control
DR-ready with live database backups and master-slave configuration
Full audit trail on every data view, entry, and modification

Context

Banks deploying CDMs as part of their self-service channel expansion face a problem that scales badly with success: every machine added to the fleet is another physical device that can jam, run low on cash, go offline, or need attention — and every one of them is sitting in a different branch, unattended, often outside normal banking hours.

Without a centralized system, "is the CDM in Macquarie working right now?" is a question that requires someone physically checking, or waiting for a customer complaint. Machine status, deposit reconciliation, and content updates (like on-screen advertisements) all lived as separate, manual, branch-by-branch problems rather than something the bank could see and act on centrally.

At the same time, every CDM deposit is a financial transaction that needs the same rigor as any other channel — logged, traceable, tied to a customer, and secured — while the CDM itself is a physical machine that needs its own operational monitoring layer on top of that.

The Challenge

The core challenge wasn't building a dashboard — it was building a switch that could sit between a distributed fleet of physical machines and the bank's systems, handling real-time device monitoring, transaction processing, and remote content management as one coherent platform instead of three disconnected tools.

This meant the system needed to:

Monitor machine-level status in real time — door, sentry, vault, printer, and receipt state — across every deployed CDM.
Alert the right people automatically when a machine went into an abnormal state, without requiring manual polling.
Log every deposit transaction centrally, tied to the machine, customer, and amount.
Extract and map transaction photos from the CDM to their corresponding transaction record.
Let the bank push content — background images, advertisements, theming — to the entire fleet remotely, instead of machine by machine.
Expose APIs and webhooks so the bank's own systems and third parties could integrate with CDM data and events.
Secure the platform to a standard appropriate for a financial system managing cash-handling devices — 2FA, encryption, role-based access, audit trails, DSS compliance.
Stay resilient — with disaster recovery readiness built in, not bolted on.

In effect, the system needed to function less like a device dashboard and more like an operations and transaction switch, with monitoring, content management, and financial logging all routed through it.

My Role

I was responsible for the architecture and development of the platform, with ownership spanning device monitoring, transaction logging, content management, and security.

My work included:

Designing the switch architecture connecting the CDM fleet to the bank's monitoring, transaction, and content systems.
Building real-time device status monitoring (door, sentry, vault, printer, receipt) across the fleet.
Designing the automated alerting system for abnormal machine states.
Building the centralized transaction logging system, including photo extraction and mapping to transactions.
Designing the open API and webhook layer for integration and event notification.
Building the remote content management system for background images, advertisements, and theming.
Implementing 2FA login, end-to-end encryption, and multilevel role-based access control.
Designing the audit trail system and DR architecture, including live backups and master-slave configuration.

The key architectural responsibility was making sure that no matter how many clients sat under a fund manager, a single trade decision reached every account correctly and with minimal delay — and that every account's accounting stayed accurate even when a trade didn't go through as planned.

Engineering Challenges

Treating a distributed device fleet as one system

The core difficulty wasn't monitoring one machine — it was aggregating live status from every machine in a fleet spread across branches into one coherent, real-time view, without that view lagging behind what was actually happening on each device. That meant the monitoring layer had to reliably ingest and reflect device-level state changes as they happened, machine by machine, without any one device's issue affecting visibility into the rest of the fleet.

Making alerting proactive instead of reactive

An abnormal machine state that only surfaces when a customer complains or an admin happens to check is already too late. Building automated alerting meant the system had to recognize an abnormal condition — out of service, out of receipt paper, door issues — and notify the right people immediately, without requiring anyone to be actively watching a dashboard for it to work.

Tying financial transactions to physical evidence

A deposit transaction record on its own doesn't tell an operator everything they might need during an investigation or dispute. Extracting photos captured during the transaction and reliably mapping them to the correct transaction record — rather than leaving that correlation to be done manually — meant the transaction and content-capture pipelines had to stay tightly synchronized, machine by machine.

Managing content across a fleet without per-machine work

Updating advertisements or branding on one machine is trivial. Doing it consistently and correctly across an entire fleet, remotely, without requiring anyone to touch a machine physically or configure it individually, meant building content distribution as a genuine fleet-wide push mechanism — with validation on format and ratio built in, since a bad upload shouldn't be able to break the display across every CDM in the network at once.

Meeting financial-system security standards on physical infrastructure

A CDM switch isn't just handling data — it's tied to cash-handling machines and real deposit transactions, which meant the security bar had to match what's expected of core financial systems: 2FA, end-to-end encryption, DSS compliance, and a full audit trail capturing who viewed or modified what, and from where. Layering that consistently across monitoring, transactions, and content management — rather than only around the transaction data — was a deliberate design decision, not just a compliance checkbox.

Reflection

This project changed how I think about systems that sit at the boundary between physical infrastructure and financial data. It's tempting to treat device monitoring and transaction processing as separate problems — one is operational, one is financial. In practice, for something like a CDM, they're the same problem viewed from two angles: a machine going out of service and a deposit needing investigation both trace back to the same physical device, at the same branch, at the same moment.

The real engineering work was building a switch that didn't force a choice between those two views — one platform that could tell an admin both "this machine needs attention" and "here's exactly what happened on it," without those being two different systems that had to be manually cross-referenced. That's the lens I bring to any system that has to manage both the physical and financial sides of the same infrastructure.

Get In touch

Feel free to email me at hi@riteshr.au for counsuting work, and I'll get back to you.