Bank bills, generated on a schedule.
Generates the bills banks owe for cash management and cash van services, across multiple states.
- Role
- Full stack engineer
- Clients
- Axis Bank, SBI and others
- At
- Oneture Technologies
- Services
- Cash management, cash van
- Year
- 2025
Billing for moving cash.
Banks pay a provider to manage their cash and to move it by van, the cash-in-transit side of banking. Every cycle, someone has to work out what each bank owes, in each state, and produce a bill.
The platform generates those bills, with one workflow for cash management and one for cash van billing.
The things that made it hard.
Rates, SLAs and deductions differ by bank and by state, so the rules have to be data, not code.
A run must be safe to repeat. A retry should never bill the same thing twice.
Finance needs to see who changed what: the person who raises a change should not be the one who approves it.
How do you bill many banks, in many states, the same dependable way?
Every bank and state brings its own rates, service levels and deductions. Coding each one separately would not scale past the first few.
3 passes at it.
Rules as configuration
- Object-oriented rate-card, SLA and deduction models.
- A new bank, state or provider is added through configuration, not a release.
- The billing schema covers GST and FASTag charges.
Bills that run themselves
- Celery workers, Redis and Python cron jobs generate bills on a schedule, in batches.
- Retries and idempotency keys mean a re-run recomputes rather than re-bills.
The workflow and the screens
- Designed the full application UI and the cash management and cash van billing workflow.
- Built the Python backend behind it.
- Maker-checker approval enforced through JWT and RBAC.
What came out of it.
The interesting part was never the bill itself. It was making sure a re-run at 2am gives the same answer as the first run.