The FOB Transaction Format

Every bank statement — whatever bank, whatever format — gets normalized into the same transaction shape. This is what makes exports and API responses consistent everywhere.

{
  "date": "2025-01-14",
  "particulars": "UPI/AMAZON PAY/50100...",
  "inflow": 0,
  "outflow": 149900,
  "balance": 4820150,
  "fingerprint": "D-(2025-01-14)-IF-(0)-OF-(149900)-P-(UPI/AMAZONPAY/50100)"
}
Human-readable

Field names an accountant or business owner can read without a schema reference — date, particulars, inflow, outflow, balance.

Machine-readable

Consistent field names and types across every bank and format, so downstream code doesn't need a special case per bank.

Integer amounts, not floats

Amounts are stored in paise/cents as integers, not decimals — so balances reconcile exactly instead of drifting from floating-point rounding.

ISO dates

Every date is YYYY-MM-DD, regardless of whether the source statement wrote it as DD/MM/YY, MMM DD, or something else entirely.

Structured metadata, not just rows

Statement-level metadata — account number, currency, statement period, opening/closing balance — travels alongside the transactions, not as a separate manual step.

See your own data in this format

Upload a statement and export the result as Excel, CSV, or JSON — or pull it through the API.