Agentic Ledger
Autonomous multi-agent financial engine.
- Started
- Sep 2026
- Stack
- PyTorch · FastAPI · Python · Docker · Phinite OS
01 · Problem
The problem
Paytm's Soundbox and merchant tools work on the happy path. Two everyday moments still cost small merchants money and trust.
- Silent Soundbox or fake payment? On a weak 2G link a genuine announcement can arrive seconds late, and fraudsters use the same moment with fake payment apps, old receipts or a real receipt with the amount edited.
- The 4 PM supplier bill: the distributor wants ₹4,500 now, the merchant has ₹6,000 of today's collections unsettled, and a ₹3,000 loan EMI comes out of the next morning's settlement. Settling everything pays the supplier but bounces the EMI.
02 · Approach
How it works
- 01One supervisor, three workersA single entry point takes payment claims, supplier bills and settlement taps, routes each to the right worker and records every outcome for an audit trail.
- 02Spoof Guard: four checksA claim is genuine only if the payment exists on the gateway, went to this Soundbox's merchant, is recent and matches the amount on the customer's screen. Genuine but never acknowledged over MQTT means "payment received, audio delayed".
- 03Bills in, PII outThe Supplier Ledger masks card, Aadhaar, phone, bank account, PAN, IFSC and UPI numbers, then extracts the total, vendor, invoice number, deadline and quantities. Any extracted amount that is not in the message is rejected.
- 04A payment plan that never touches the EMIPay from the balance above the EMI reserve if the bill fits; otherwise cover the gap with a short advance, only if it fits both a pre-approved limit and the conservative floor of a PyTorch LSTM forecast of tonight's sales; otherwise pay what is safe and defer the rest. The forecast never approves anything on its own, and an independent checker re-verifies every plan.
- 05Settlement that fails safelyRequests are signed with HMAC-SHA256 over the exact bytes and a timestamp, each payout keeps one order ID and idempotency key across retries, and after a bank timeout the order's status is checked before anything is resent. A FastAPI sandbox stands in for the gateway and bank, a Streamlit app for the merchant's phone, and Docker Compose runs it all.
03 · Architecture
Architecture
Follow a vendor bill and a payment ping through the agents.
- 01Events arrive
Soundbox payment pings over MQTT and supplier bills through a WhatsApp webhook.
- 02The supervisor routes them
Security events and financial events go down different paths inside Phinite OS.
- 03Spoof Guard checks the payment
Four gateway checks decide: fraud alert, verified, or "payment received, audio delayed".
- 04The ledger reads the bill
PII is masked and the amount owed (₹4,500 in the demo) is extracted.
- 05An EMI-safe plan
₹3,000 is safe above the EMI, so the plan pays that and covers ₹1,500 with an advance that fits the forecast floor.
- 06Signed, idempotent settlement
A checker re-verifies the plan; signed, timeout-aware calls pay the supplier exactly once.
04 · Results
Results
- agents: a supervisor and three workers
- 4
- LSTM forecast error (MAPE) on held-out test days
- 16.9%
- test days at or above the conservative floor
- 88.7%
- rows of synthetic retail data
- 400,000
- PyTorch LSTM16.9%
- Morning × recent evening/morning ratio20.2%
- Mean of the last 3 evenings28.2%
- Recent daily average − morning45.0%
In the demo, the ₹4,500 bill becomes ₹3,000 from the balance plus a ₹1,500 advance, and the ₹3,000 for the EMI stays untouched.
The training data is a synthetic retail dataset with no time of day, so the morning/evening split is simulated: these numbers show the pipeline beats simple baselines on held-out data, not how it would do for real merchants.