Operate a Payment Waterfall Across Calculation, Review, and Release

The waterfall calculation is only the middle of the operation

A payment waterfall answers an ordered question: given accepted funds and terms, how much is allocated to each priority? The arithmetic may be deterministic. The operating chain around it is not merely arithmetic.

Terms owners establish what governs. Source systems report cash and performance facts. One role prepares the calculation; another reviews it. Authorized roles resolve exceptions and release instructions. External responses return for reconciliation, accounting, and reporting.

Calling all of those acts “run the waterfall” hides essential controls. Keeping them in unrelated files lets terms, facts, approvals, instructions, and reports refer to different states.

This use case describes an operating pattern for keeping the chain connected. It does not interpret an agreement, decide that a payment is due, authorize or transmit funds, provide custody, determine accounting treatment, perform an audit, value an instrument, or provide financial, legal, tax, or investment advice.

Map the present chain artifact by artifact

Many teams can recognize some version of this workflow, although the parties, systems, controls, and legal duties vary by transaction and institution.

Current artifact	Work it performs	Break to look for
Executed terms and approved interpretation	Defines priorities, caps, triggers, dates, rounding, and permitted exceptions	A spreadsheet implements a draft or superseded interpretation
Servicing or cash-source file	Supplies collections, balances, fees, and performance facts	Corrections or effective times do not reach the calculation
Calculation workbook or service	Applies priorities and produces intermediate and final amounts	Hidden formulas, manual plugs, local overrides, or copied logic drift
Review package	Explains sources, terms, exceptions, and variances	Reviewer sees totals without the reason path or wrong revision
Approval record	Records who accepted the calculation or exception	Login access is mistaken for transaction authority
Treasury or payment file	Converts approved amounts into a downstream instruction format	A field is omitted, altered, duplicated, or released before approval
Bank, custodian, or payment response	Reports acceptance, rejection, settlement, or other status	A submitted file is labeled paid before external evidence arrives
Ledger and reporting outputs	Records and presents activity for their governed purposes	The report recomputes the waterfall or masks a reconciliation difference

For asset-backed securities within Regulation AB's scope, current 17 CFR § 229.1113 calls for disclosure of flow of funds, payment priorities, reserves and expenses, principal formulas, and structural triggers. It calls for a graphic when that aids understanding. This scoped disclosure rule is not a universal operating design, but it shows the meaning behind an allocation table.

Current 17 CFR § 229.1122 provides equally useful scoped examples in its servicing criteria: mathematical accuracy, authorized wire disbursement, separate accounts, review of reconciliations by someone other than the preparer, explanations of reconciling items, and allocations according to transaction terms. Applicability depends on the rule's framework and the party's activities. The section should not be generalized into a control mandate for every payment process.

Establish one calculation contract

Before encoding formulas, the responsible owners should agree on the contract that the calculation consumes and produces.

Contract element	Questions the implementation must answer
Governing terms	Which source and accepted interpretation apply, over what effective period, and who may approve a change?
Source facts	Which accounts, balances, collections, fees, rates, dates, and performance measures are accepted, corrected, disputed, or missing?
Priority logic	What is paid first, what is capped, what can be deferred, how is a shortfall handled, and where does residual cash go?
Precision	Which currency, units, day-count, decimal precision, and rounding convention apply at each step?
Triggers	Which fact and comparison change the priority, and what happens exactly at the boundary?
Exceptions	What may be proposed, what evidence is required, who can approve it, and what must stop while it remains open?
Invariants	Must sources equal uses? Which account, class, and report totals must reconcile?
Output state	Is the result draft, reviewed, approved, instructed, accepted, settled, rejected, corrected, or reversed?

The contract must preserve state. A balanced draft is not reviewed; an approved calculation is not released; acknowledgment is not necessarily settlement; and settlement does not determine accounting or reporting conclusions.

Worked example: a synthetic distribution with a trigger

This is a small, reproducible test calculation. It does not represent a company, customer, security, offering, account, investment, or real transaction. The amounts and terms exist only to demonstrate the operating chain.

Accepted synthetic funds are $1,000,000. The priority rules are:

1. Administrative expense, capped at $40,000
2. Senior interest of $300,000
3. Reserve top-up of $100,000
4. Scheduled senior principal of $400,000
5. Subordinate interest of $80,000
6. Residual cash, unless a delinquency measure is at least 4.000%; when the trigger is active, redirect residual cash to senior principal

The submitted administrative expense is $45,000. The rule pays the $40,000 cap and leaves a $5,000 exception unresolved; it does not invent authority to waive the cap or take the difference from another priority.

Priority	Requested or calculated	Paid with trigger below 4.000%	Cash remaining
Starting funds	$1,000,000	—	$1,000,000
Capped administrative expense	$45,000	$40,000	$960,000
Senior interest	$300,000	$300,000	$660,000
Reserve top-up	$100,000	$100,000	$560,000
Scheduled senior principal	$400,000	$400,000	$160,000
Subordinate interest	$80,000	$80,000	$80,000
Residual	Remaining cash	$80,000	$0

The reproducible base calculation is:

$1,000,000 − $40,000 − $300,000 − $100,000 − $400,000 − $80,000 = $80,000 residual

The accepted delinquency measure initially equals 3.800%, so the trigger is false and the $80,000 remains residual. A source correction changes that measure to 4.200%. Nothing else changes. Because 4.200% >= 4.000%, the trigger becomes true and the remaining $80,000 moves to senior principal.

Result	Trigger below 4.000%	Trigger at or above 4.000%
Administrative expense	$40,000	$40,000
Senior interest	$300,000	$300,000
Reserve top-up	$100,000	$100,000
Senior principal	$400,000	$480,000
Subordinate interest	$80,000	$80,000
Residual	$80,000	$0
Total uses	$1,000,000	$1,000,000

Boundary tests should also run at 3.999%, 4.000%, and 4.001%. Under the declared >= rule, only the first value leaves residual cash. If a downstream payment file omits the $100,000 reserve top-up, its total is $900,000 rather than $1,000,000. The sources-equal-uses invariant must fail and stop release; a balanced calculation elsewhere cannot excuse an out-of-balance instruction.

The $5,000 over-cap amount remains a separate exception in both states. Only the role recognized by the governing process may resolve it; the fixture assumes no legal permission or suitability for real use.

Give every role the same calculation without giving every role the same power

Role	Required view	Action boundary
Terms owner and qualified advisers	Cited terms, accepted interpretations, effective dates, amendments	Interpret and approve terms through the actual governing process; Grid cannot do so
Source-data owner or servicer	Accepted cash and performance facts, corrections, disputes, as-of times	Attest to or correct its records within its responsibility
Calculation preparer	Inputs, every allocation step, caps, triggers, precision, invariants	Prepare a result; cannot self-supply missing authority
Independent reviewer	Source-to-result lineage, boundary cases, exceptions, comparison to expected results	Review, challenge, reject, or escalate under the applicable control
Exception approver	Amount, reason, evidence, permitted treatments, impact	Approve only within actual delegated authority
Treasury preparer	Exact approved schedule and permitted account references	Prepare an instruction; cannot approve or release merely by preparing it
Authorized releaser	Approved instruction, segregation evidence, release conditions	Authorize the external action under institutional controls
Reconciliation, accounting, and reporting	External responses, settlement evidence, calculation and instruction totals	Reconcile and apply separately governed accounting and reporting judgments

The 2023 Interagency Guidance on Third-Party Relationships describes a risk-based lifecycle for banking organizations supervised by the Federal Reserve, FDIC, and OCC. It emphasizes that using a third party does not remove the banking organization's responsibility for safe, sound, and compliant activity. The guidance does not have the force and effect of law or impose new requirements. In this use case, it supports a bounded operational principle: outsourcing software or calculation work does not outsource institutional accountability.

The agencies' April 2026 Revised Guidance on Model Risk Management supersedes earlier guidance and takes a risk-based approach. Its scope excludes simple arithmetic and deterministic rules not grounded in statistical, economic, or financial theories. Grid execution does not transform a deterministic waterfall into a regulated model. The responsible organization must separately classify and govern any embedded loss, prepayment, valuation, pricing, or other model.

The Grid operating pattern

Grid can represent accepted terms, facts, calculation, exceptions, permissions, and output states as connected versions. A changed fact recalculates the affected path; explanations show applied terms, intermediate values, trigger result, and invariants. Purpose-specific views project the same state without copying the formula.

An AI assistant may help draft a rule, map a field, or explain a variance, but its output remains attributed and unapproved until the responsible owner accepts it. A configured integration may prepare a downstream message, but external release remains behind the institution's identity, segregation, and authorization controls. Responses return as new evidence rather than being inferred from submission.

This pattern is intentionally narrower than “automate treasury.” It makes the handoffs testable: source acceptance, calculation, independent review, exception disposition, approval, instruction preparation, external release, response, reconciliation, correction, and reporting.

Integration and security boundaries

Adapters must be tested against the actual servicing, treasury, bank, custodian, ledger, reporting, and identity systems. Mappings need explicit currency, sign, precision, account, date, and effective-time semantics. Events need ordering, correction, idempotency, and failure handling. A retry must not become a duplicate payment.

Use least-privilege service and human identities, separation of duties, authenticated approvals, encrypted transport and storage, protected secrets, tamper-evident logs, and environment-specific monitoring. Views must suppress account, counterparty, investor, personal, and confidential information that a role does not need. Data retention, records, privacy, cybersecurity, business continuity, and incident response remain governed by the organization and its applicable obligations.

Grid does not connect to or move money through external systems automatically. It does not confer access, transaction authority, custody, bank acceptance, settlement finality, or approval. Those boundaries need explicit integration and customer-controlled testing.

Test the chain by trying to break it

A credible evaluation starts with synthetic cases or appropriately controlled historical cases and an independently prepared oracle. The responsible owners freeze the terms, source facts, precision, role matrix, expected results, exception states, and stop conditions before testing.

Failure case	Required acceptance behavior
Draft or future term supplied	Reject it for the current calculation and show the governing version
Trigger values 3.999%, 4.000%, and 4.001%	Apply the declared boundary exactly and reproducibly
Duplicate collection or sign reversal	Fail source validation before allocation
Expense above the cap	Pay only the represented cap and preserve the unresolved exception
Preparer attempts to self-review or release	Block the action under the configured separation rule
Payment file omits the reserve top-up	Fail sources-equal-uses reconciliation and stop release
Approval followed by a material source correction	Invalidate or supersede the approved state as predefined; retain both histories
Connector timeout followed by retry	Preserve one attributable instruction intent and prevent an ungoverned duplicate
Role view exposes prohibited fields	Fail access and view-integrity testing
External rejection or partial response	Report the returned state without calling it settled

Acceptance evidence should show exact arithmetic, correct versions, intermediate values, deterministic replay, blocked unauthorized actions, explained exceptions, consistent permitted views, reconciled totals, and reconstructable corrections. Set performance, resilience, security, and usability thresholds before the run and report every miss.

A passing test supports only behavior in the declared cases and environment. It does not prove the terms are valid, a payment is due, the accounting is correct, controls are sufficient, a model is validated, a transaction complies with law, or financial outcomes improve.

Read One Waterfall, Many Accountable Views for the deeper architecture and regulatory scope, compare private formula copies in From Spreadsheet to Shared Model, and use the decision evaluation worksheet to define the baseline and acceptance evidence.

Primary sources

• 17 CFR § 229.1113 — Structure of the transaction
• 17 CFR § 229.1122 — Compliance with applicable servicing criteria
• Interagency Guidance on Third-Party Relationships: Risk Management, June 2023
• Federal Reserve SR 26-2 — Revised Guidance on Model Risk Management, April 2026