Inflated income and edited balances drain loan books before the first repayment. TrueSecurix re-runs the statement's own arithmetic, and when the running balance or the totals do not add up, you get proof instead of a hunch.
We recompute the statement line by line. A balance that does not follow from its own debits and credits is unambiguous tampering.
Payslip earnings, deductions and net pay are reconciled. Figures that cannot be made consistent are routed for review.
Structural inconsistencies across a statement's pages surface documents assembled from more than one source.
Post the PDF to /v1/verify. We parse the transactions and re-run the reconciliation the document claims to satisfy. Clear tampering flags; anything ambiguous routes to review rather than a wrongful rejection.
Read the API docs
curl https://truesecurix.com/v1/verify \
-H "X-API-Key: sk_live_..." \
-F document=@statement.pdf
# => "reconciles": false, "off_by": "~ Rs 30,000"We re-run the statement's own running-balance and total arithmetic. A statement whose debits and credits do not reconcile to its stated balances has been altered, which is a deterministic result, not a probability.
Genuine statements reconcile, so they pass. Where a figure is genuinely ambiguous, for example reimbursements or arrears on a payslip, the case is routed to human review, never auto-rejected.
Common bank statement and salary-slip layouts today, with more formats on the roadmap. The reconciliation math is format-independent once the figures are parsed.
100 verifications free, no card. Point it at your income documents.