OpenChainGraph Suite · ART-509 · Securitisation · Investor Due Diligence

Securitisation Payment Waterfall Recomputation

Runs the priority ladder from your own transaction documents against the funds available for one period, and tells you what each step should have received. Where you also paste what the investor report says was paid, the two are compared step by step. The left side of that comparison is computed here from the ladder, not copied from the report, so it is an independent recomputation rather than a re-adding of published totals. Pairs with the ART-510 Article 5 Due Diligence Evidence Record.

Caller supplied ladder Caller supplied thresholds Fixed-point money math No disclosure template read

Basis: the priority of payments as you declare it from the transaction documents · no deal library, no bundled ladder, no market convention threshold · field set v1.0.0

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.

⚠ Loan level securitisation data is confidential and often personal, and this arithmetic needs none of it: aggregate available funds and a declared ladder are the whole input surface. Fields this page does not map are ignored and never appear in the receipt. A shortfall, or a difference against the investor report, is an arithmetic finding about the ladder and figures you supply. Whether the deal was paid correctly is for the transaction documents, the cash manager and the trustee. This page computes once when you press the button, stores nothing, runs on no schedule, and retains nothing.

Period and ladder reference

The demo deal below is synthetic. It is not a copy of any real transaction, and it is already loaded so you can press Run without entering anything of your own.

Period label (your input, never a clock read)

Deal reference

Currency

Ladder document reference

Ladder section reference

Ladder version and date

Available funds by ledger

JSON array: ledger, amount_minor_units. Supply one row if you do not split interest and principal.

Priority ladder

JSON array in payment order: step_id, label, ledger, amount_due_minor_units, optional cap_minor_units, optional amount_source of recomputed or asserted

Tests

JSON array, optional. Each test carries YOUR threshold and, where the documents divert on failure, the step ids that failure suppresses.

What the investor report says was paid

JSON array, optional: step_id, amount_minor_units. Leave empty and the run is reported as recompute only, which is not agreement.

Allocation down the ladder

Residual by ledger

Tests

Against the investor report

Rejected inputs

Rationale

Execution Hash (SHA-256)

What this does not do

It does not forecast, project or model a scenario. It recomputes a stated period and nothing else. It performs no credit or rating analysis, it does not verify the completeness of the figures you supply, and it makes no assertion about whether the transaction complies with anything. It reads no Article 7 disclosure template, checks no field set and asserts conformance with no annex: the priority of payments comes from the transaction documents you already hold, which is exactly why the disclosure templates being revised cannot reach this arithmetic. Steps you mark as asserted, such as a trustee fee set by a fee letter that is not public, are allocated exactly as you supply them and are reported as asserted inputs rather than as figures derived here.

Feeds ART-510 Article 5 Due Diligence Evidence Record, where a recomputation for the period is the evidence behind the ongoing monitoring duty. See also ART-447 Securitisation Risk Retention Check.