Custom enterprise software · 2011

Banknote circulation analytics — reading counting machines directly

A cash-management platform for Xin'anxian that reads its note-counting machines directly rather than relying on branch reports, producing regional counterfeit distribution, counting statistics and escort tracking on DB2.

Client · Xin'anxian Industry · Banking / cash handling equipment Delivery · Custom platform + hardware integration Status · Delivered
Direct from the machines Data capture
DB2 Data platform
Region / industry / counterfeit Analysis

The situation

Xin’anxian builds note-counting and counterfeit-detection machines, several of them patented, and was moving from selling equipment to selling a complete cash-management solution — for banks, for public-security buyers and for enterprises that handle large volumes of cash. The machines were already sitting in the branches. What was missing was the picture above them: how much cash moves through which region, where counterfeit notes are being found, and where the escorted shipments are.

The obvious build was a reporting website: branches log in every week, type in their counting totals and any counterfeit finds, and the system draws charts. That is a normal enterprise request, and it would have failed for a structural reason. The data that makes the product worth buying is not something a branch clerk can report accurately. A counting total is an aggregate of thousands of individual machine runs held on the device; a counterfeit detection is one event, with a time and a serial number; and by the time a weekly figure has been typed in, the detail is gone and the incentive to round is present.

The call we made

Connect the machines. The counting machine is the point of truth, so we made it the point of entry. The system reads over the hardware interface as notes are counted and records each run as it happens, rather than asking a person to summarise it later. Everything downstream — regional distribution, industry breakdown, counterfeit concentration on a map, escort tracking — is a query over that captured stream.

Three consequences followed from that decision, and they shaped the build:

  1. The raw record has to stay raw. Once a machine reading is captured it is not edited. Corrections, re-counts and disputed runs are recorded as separate adjustments that point back at the original event. An operator can see both the figure the machine produced and the figure the books ended up with, and can see why they differ. Without that split, a system that talks to hardware becomes less trustworthy than a form, because nobody can tell a machine error from a human one.
  2. Storage was chosen for append-heavy, high-volume records. The data is many small events, written continuously and read back in large aggregations. We built on DB2, which the deployment required, and kept the analytical queries off the capture path so that a slow report cannot delay a counting run at a counter.
  3. Regional and industry views are first-class, not a chart at the end. The customer’s commercial argument to a bank is that cash flow and counterfeit risk are unevenly distributed and can be measured. A system that shows only today’s total does not support that argument, however good the total looks.

We also drew a scope line: the system reports on cash, it does not move it. Escort-vehicle tracking is a management view of tasks and routes — where a run originated, what it carried, whether it completed — not a real-time dispatch product. Promising dispatch would have meant a different system with a different buyer and a different field-support burden.

What we built

  • Direct capture from counting machines over the hardware interface, with counting, denomination, counterfeit detection and locked-data records written as events.
  • Regional statistics of cash circulation, so that the distribution of notes between areas is read rather than estimated.
  • Industry statistics, separating how different sectors use cash — the pattern differs enough that a single national figure conceals the business question.
  • Counterfeit distribution, presented on a map so that concentration by area is visible rather than inferred from a table.
  • Locked-data tracking, following exceptional records through to resolution instead of leaving them as an unexplained count.
  • Escort-vehicle tasks and routes, so that a shipment can be tied to the cash it carried.
  • Multi-dimensional analysis by region and industry over the same captured dataset, without a second data store.

Result

The engagement turned a hardware vendor into a solution vendor: the machines became the sensor network and the platform became the thing a bank or a public-security buyer could procure as a whole. Reporting moved from a reporting cycle to the moment of counting, and the counterfeit map is the view that shows a buyer something they did not already know.

The less visible result is trust. Because the raw machine record and the corrected record are both visible, a disputed count can be settled with evidence rather than an argument between two offices. In a cash business, that is the property that keeps the system in use after the pilot.

If you have hardware in the field that already knows more than your reporting layer does, that is the conversation worth having.

Technology

StackDB2 · Hardware serial port · Vue 3 · ECharts · Java + Spring Boot
Delivery modelCustom platform + hardware integration
ClientXin'anxian
StatusDelivered

What we cannot show

Note serial numbers, branch-level counting records, counterfeit findings and escort routes are operational customer data and are not published. The views shown are from the delivered system.

Similar problem?

If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.

Ask about this project