One Waterfall, Many Accountable Views

The numbers can agree while the work does not

A waterfall is often presented as a clean sequence: available cash enters at the top, priorities consume it in order, and the remainder exits at the bottom. The arithmetic may fit on one page. The operating reality does not.

Terms live in executed documents and approved interpretations. Collections arrive from servicing systems. Fees come from invoices. Triggers depend on dated performance facts. A calculation agent applies priorities. Treasury prepares a payment instruction. Another person authorizes it. Accounting maps activity to books and records. Reporting teams publish reports tailored to their audiences. Risk, compliance, legal, audit, trustees, administrators, investors, and counterparties may each need different evidence and have different authority.

When those teams maintain private copies, a correct total can conceal the wrong term revision, a stale trigger, an unapproved exception, or a payment file that no longer matches the calculation. When they are forced into one universal screen, access and responsibility blur. The design question is not how to make every role identical. It is how to keep one accepted semantic calculation coherent while each role receives an accountable view and retains its actual duties.

This paper first describes several scoped federal requirements and supervisory statements. It then presents a separate Grid proposition and a fictional evaluation. The cited institutions do not describe or endorse Grid, and their rules and guidance do not apply universally to every waterfall, treasury process, firm, or transaction.

What selected official sources establish

For asset-backed securities within Regulation AB's scope, the current electronic text of 17 CFR § 229.1113 requires disclosure of the transaction structure. That includes the flow of funds, payment allocations and distribution priorities, cash directed to reserves or expenses, formulas affecting principal, triggers that change the structure, parties with access to cash balances, investment or disbursement authority, fees, and disposition of excess cash flow. The rule calls for a graphic presentation when it would aid understanding.

That is a disclosure requirement for covered offerings, not a universal blueprint for operating financial logic. The eCFR is an authoritative but unofficial, continuously updated codification rather than the official legal edition. Section 229.1113 does not authorize a transfer, interpret transaction documents, determine that a calculation is correct, or assign duties in a transaction outside its scope.

Regulation AB also supplies unusually concrete control examples. Under 17 CFR § 229.1122, each covered party participating in the servicing function provides a scoped assessment of the servicing criteria applicable to it, with related attestation and disclosure provisions. The criteria address monitoring contractual triggers, mathematically accurate aggregation, authorized wire disbursements, separate maintenance of specified accounts, and monthly account reconciliations that are reviewed by someone other than the preparer and explain reconciling items. They also address investor reporting and allocations according to transaction terms.

Those criteria attach through Regulation AB's reporting framework and include detailed applicability instructions. They are not general requirements for every treasury process, private securitization, calculation agent, or software platform. Still, they demonstrate why “the total matches” is not the whole control claim: applicable responsibility, authorization, independent review, exception explanation, and agreement to underlying records remain distinct.

For banking organizations, the 2023 Interagency Guidance on Third-Party Relationships from the Federal Reserve, FDIC, and OCC describes a risk-based lifecycle spanning planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. It says use of a third party does not diminish a banking organization's responsibility to conduct its activities safely, soundly, and in compliance with applicable law. It also discusses oversight, internal controls, independent reviews, documentation, and reporting. The guidance applies to banking organizations supervised by the issuing agencies and expressly does not have the force and effect of law or impose new requirements. A vendor-produced waterfall therefore does not transfer the bank's responsibility to the vendor, but the guidance should not be recast as law for every financial institution.

The agencies' April 2026 Revised Guidance on Model Risk Management superseded SR 11-7 and SR 21-8. It is expected to be most relevant to banking organizations with more than $30 billion in assets, uses a risk-based approach, and says it does not set enforceable standards or prescriptive requirements. It discusses purpose, use, testing, validation, monitoring, effective challenge, governance, defined roles, documentation, and vendor products.

Scope is important here. The attached guidance defines a model as a complex quantitative method grounded in statistical, economic, or financial theories, and excludes simple arithmetic and deterministic rule-based processes without such theories. It also excludes generative and agentic AI from its scope. A deterministic payment waterfall is not transformed into a validated regulatory model because it is implemented in Grid. If a workflow incorporates a loss, prepayment, pricing, valuation, or other model, the responsible organization must classify and govern that component under its applicable framework. This paper neither performs nor substitutes for model validation.

The Grid proposition: one semantic waterfall, bounded views

Grid proposes representing the accepted calculation as a versioned executable package rather than copying formulas into each role's workbook, report, and interface. The package can keep several objects connected without claiming they have the same legal status:

• Terms: cited provisions, approved interpretations, priorities, caps, rounding rules, triggers, effective intervals, owners, and superseded revisions.
• Facts: collection balances, fees, reserve levels, performance measures, source and observation times, corrections, disputes, and declared uncertainty.
• Calculation: available-funds construction, ordered allocations, constraints, residual handling, and invariant checks, with intermediate values retained.
• Exceptions: an authored reason, affected amount, permitted treatment, evidence requirement, approving role, and stop or escalation state. An unexplained plug is not an exception policy.
• Authority: who may propose, review, accept a term interpretation, approve an exception, authorize an instruction, release a report, or correct a record—and when a second person is required.
• Views: explicit projections for each role, with the same calculation revision and distribution identity but only the fields, actions, and explanations that role needs.

One waterfall therefore does not mean one screen. A servicer view can expose collection provenance and adjustments. A calculation view can expose every allocation step. A treasury view can receive only an approved schedule and configured account references. A controller view can map accepted amounts to a separately governed ledger treatment. A reporting view can assemble an approved statement. A risk or audit view can reconstruct sources, changes, controls, exceptions, and authorizations. No projection should silently invent a second formula.

Generated logic remains a proposal until qualified owners accept it. A correct calculation remains distinct from a payment instruction; an instruction remains distinct from authorization; authorization remains distinct from bank acceptance, settlement, custody, accounting recognition, and external reporting. AI Can Propose. Who Authorizes? develops that boundary, while One Program Rule, Many Public Surfaces examines the related problem of one governed rule serving different audiences.

Grid provides no financial, investment, legal, or accounting advice. It does not confer transaction authority, hold or move funds, provide custody, price or value a security, make a credit or eligibility decision, discharge fiduciary duties, perform model validation, or establish deployment, compliance, certification, returns, loss reduction, or any other outcome. Contract interpretation, accounting treatment, legal duties, control ownership, access, and approval remain with the responsible parties.

Fictional fixture: North Cove Equipment Receivables 2028-1

The following structure, parties, dates, documents, assets, and amounts are wholly fictional. North Cove Equipment Receivables 2028-1 is a synthetic, non-live evaluation fixture, not an offering, investment, recommendation, valuation, transaction, or representation of an existing deal.

For the invented October 15 distribution, accepted source revision C-104 reports $8,400,000 in collection-account cash and $600,000 in recoveries. Terms revision WF-3.2 treats both as available, producing exactly $9,000,000 of represented funds. The table keeps the authored priority, governing treatment, baseline result, and corrected result in one inspectable view:

The arithmetic is inspectable: $9,000,000 − $200,000 − $1,800,000 − $300,000 − $5,000,000 − $900,000 = $800,000. A $220,000 fictional expense invoice leaves $20,000 above the represented cap. The calculation allocates neither that difference nor an invented substitute. It records an unresolved exception for the authorized fictional role.

Performance source P-17 initially reports 3.80% delinquency, so calculation revision D-104a assigns $5,000,000 to Class A principal and $800,000 to residual. A later source correction, P-18, reports 4.20%. The changed fact produces D-104b: the first five priorities are unchanged, the trigger is now true, Class A principal becomes $5,800,000, and residual becomes zero. Both calculations total $9,000,000; the first is preserved rather than overwritten.

A draft terms revision, WF-3.3, would raise the expense cap, but its fictional approval and effective date are absent. The expected fixture disposition rejects its use for this distribution. A technical operator also tries to mark the $20,000 exception approved; the expected authorization control blocks the attempt because the role lacks that authority.

Each view now has a testable contract. Servicing sees C-104, P-17, and the correction to P-18. The calculation reviewer sees terms, intermediate arithmetic, trigger transition, and the open fee exception. Treasury sees D-104b only after the fixture's named approval step, but Grid still does not authorize or transmit money. The controller sees a proposed mapping, not an accounting conclusion. Oversight sees the old and new results, rejected term revision, blocked role action, approvals, and timings. A simulated downstream file that omits the $300,000 reserve top-up totals only $8,700,000; the expected result is a reconciliation failure and a stopped fictional handoff.

This exercise demonstrates only expected behavior for declared fixtures. It does not establish that the terms are valid, that the roles match any real agreement, that a payment is due, or that any financial statement, investor report, control, or transaction is correct.

Evaluate the chain, not a polished output

Begin with one distribution type and synthetic or appropriately controlled historical cases. Freeze the term sources, accepted interpretations, role matrix, account map, expected calculations, rounding conventions, exception paths, and acceptance thresholds. Baseline the current process before introducing Grid: formula copies, rekeys, version disputes, elapsed calculation and review time, unexplained reconciling items, correction effort, authorization evidence, and time required to reproduce a prior distribution. Do not assume improvement.

Seed failures deliberately: stale terms; the wrong effective date; a duplicate collection; a sign or unit error; a rounding residue; a trigger boundary at 3.999% versus 4.000%; an over-cap fee; an unauthorized term or exception change; a missing source; conflicting performance revisions; an out-of-balance downstream file; a role view exposing prohibited fields; a correction after approval; a vendor interruption; and an unauthorized instruction attempt. Predefine whether each must reject, remain unresolved, recalculate, request review, or stop.

Measure at least six groups:

• Arithmetic and invariants: expected allocations match to the declared precision; sources equal uses; priorities, caps, and rounding behave at boundaries.
• Version fidelity: the correct terms and facts apply by effective time; stale, future, superseded, and disputed revisions remain visible and controlled.
• Authority and exceptions: prohibited actions are blocked; open exceptions cannot masquerade as approval; required reviews and separation of duties are evidenced.
• View integrity: every projection names the same distribution and calculation revision; allowed differences are explicit; unintended disclosure and private formula forks are detected.
• Reconciliation and correction: source, calculation, proposed instruction, response, and record totals remain distinct and reconcilable; corrections create linked revisions without erasing history.
• Reconstruction and resilience: an evaluator can reproduce each result and action; connector failures, retries, overrides, and recovery tests are attributable.

Retain the baseline, source fixtures and hashes, term and model revisions, expected results, role assignments, test scripts, intermediate calculations, exceptions, approvals, rejections, simulated adapter responses, reconciliations, timings, and evaluator notes as receipts. Set thresholds before the run. A missed authority, source, priority, or reconciliation control should fail the evaluation rather than disappear inside a composite score.

Keep the evidence ladder explicit. Official-source analysis supports a research-grounded claim about selected responsibilities and boundaries. Passing the North Cove fixture may support a product-demonstration claim only for its declared terms, facts, roles, adapters, and cases. A customer-controlled claim requires the customer to control the material inputs, environment, cases, operators, and acceptance conditions; claims about intended use require evidence from the intended environment. Independent validation requires a suitably qualified evaluator and declared scope. No rung by itself establishes advice, authority, custody, valuation, fiduciary performance, model validation, legal or accounting sufficiency, compliance, deployment readiness, returns, loss reduction, or financial outcomes.

Teams can follow the complete operating chain in Operate a Payment Waterfall Across Calculation, Review, and Release, trace a correction through From a Changed Fact to Coordinated Action, record acceptance evidence in the decision evaluation worksheet, test the migration from private copies in From a Spreadsheet to a Shared Model, and continue with Grid Developers guidance for explaining and validating a changing result and canonical examples.