Skip to main content
DoneThat

AI Adoption GuideBankingClose

Balance and payment reconciliation agent

Agentic system reconciles pending transactions, standing orders, and direct debits across core banking, payments, and lending before account zeroing.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

Do not zero while credits, mandates, or lending are still live

A close-ready pack is a cited inventory of pending items, live mandates, and lending positions. The agent does not zero the account. A human confirms zeroing only when those cites show nothing left to settle. If every source already returns empty, the pack stays empty. Inventing a zero to finish the queue is a quality failure, not a shortcut.

Closures and payments-ops leads lose money and trust when an account is marked settled while a credit is still in flight, a direct debit mandate is still live, or a lending product still shows a balance. Core ledgers often look clean hours before the scheme, the mandate store, and the lending book agree. This agent holds zeroing until they agree, then hands a human a pack they can sign.

The pack sits beside closure reason classification so ops know why the customer left, and beside a regulatory exit compliance check so legal and conduct obligations are not treated as the same work as cash and mandates.

Pull pending from core, payments, and lending as separate cites

Pull three independent pending views. Do not net them into one remaining-balance figure and call that the truth.

From core banking, take posted and unposted items on the account being closed: pending credits, pending debits, holds, and in-progress book transfers. Platforms in the Temenos class typically hold the customer and account ledger. Treat that extract as one cite, not as the close.

From payments, take scheme-pending inbound and outbound payments, standing orders that have not been cancelled, and direct debit mandates still active against the sort code and account number. A mandate that will collect next week is a live obligation even if today's ledger is zero.

From lending, take linked overdrafts, revolving credit, and any residual principal or fees on products that share the customer or the account being closed. A current-account close that ignores a lending balance invents emptiness the book does not support.

Salesforce-class case and CRM records are not a fourth ledger. Use them to attach the close case, the customer's instruction, and the exception thread. Do not treat a closed case status as proof that payments or lending are clear.

For each cite record source system, account or mandate identifier, item type, amount and currency where the source supplies them, value date or next collection date, and the raw status the source actually returned. If a source times out or returns incomplete, the pack is incomplete. Incomplete is not empty.

Unmatched items stay on the pack until they clear or cancel

List unmatched items in the open. Unmatched means the three cites do not tell the same story about the same obligation.

Typical unmatched rows include a payments-scheme credit that has not posted to core, a core pending debit with no matching payments instruction, a standing order still scheduled after the customer asked to close, a direct debit mandate still live at the scheme while core shows the account blocked for new payments, and a lending balance with no corresponding hold on the current account.

The agent does not match away an item by guessing. It groups candidate pairs when identifiers and amounts align, and it leaves the rest unmatched. Unmatched items block zeroing. They can move to agentic end-to-end case resolution when a human has to cancel a mandate, recall a payment, or wait for a scheme cycle. They do not disappear to make the close look done.

If pre-closure churn interception already retained the customer, stop the close pack. Do not keep chasing zero on an account that should stay open.

Take a retail current account in close. Core shows a nil available balance. Payments still holds a pending inbound salary credit with a future value date, a gym membership direct debit mandate with a collection due in the next cycle, and a standing order to a savings pot. Lending still shows a small arranged overdraft with accrued interest. The agent produces a pack with four cited open items, not a zero. Ops cancel the standing order and the direct debit, wait for the salary to post or to be redirected, settle or migrate the overdraft, then a human confirms zeroing. Had ops zeroed from core alone, the inbound credit would have had nowhere to land, the gym would have attempted a collection against a closed account, and lending would have been left with a balance the close pack claimed did not exist.

Block zeroing for pending inbounds, live DDs, and leftover lending

Zeroing is blocked while any of these remain: a pending inbound credit, a live mandate (direct debit or standing order), or a lending position that still shows a balance or fee.

Closing over a pending inbound is the first failure mode. The credit arrives after the account is gone. The customer, the employer, or the scheme then opens a tracing case. The agent must treat scheme-pending inbounds as open items even when core has not booked them. A core extract taken before the scheme cycle is not evidence that the credit will never arrive.

Missing a live direct debit is the second. Cancellation on the bank's instruction log is not the same as a dead mandate at the scheme. If the mandate is still live, the next collection will fail or hit a residual account, and the originator will retry or raise an unpaid. The pack must cite the mandate store, not only the last posted direct debit. Standing orders follow the same rule: a cancelled standing order in core with a still-scheduled payments instruction is unmatched, and unmatched blocks zeroing.

Inventing a zero when lending still shows a balance is the third. Ops sometimes read a current-account ledger of zero and assume the relationship is clean. Lending is a different book. If it still shows principal, interest, or fees, the close pack is not empty, and the human must not confirm zeroing. Migrating, settling, or explicitly excluding that product under a documented exception is ops work. Silent omission is not.

When all three cites return no pending items, no live mandates, and no lending balance, the pack is empty and stays empty. The agent does not fill it with estimated residuals or with a synthetic cleared row.

Human confirms empty; the agent never invents a zero

The human's job is narrow: read the cites, confirm that unmatched items are gone or owned by a live exception case, and then confirm zeroing. The agent prepares the pack. It does not press the zero.

Confirmation is refused when any cite is stale, missing, or contradictory. Stale means the extract is older than the close team's agreed freshness window for that source. Missing means core, payments, or lending did not respond. Contradictory means one source still shows an open item another source has already dropped without a matching cancellation or posting.

After the human confirms, the pack is the audit trail: pending items (or none), mandates (or none), lending (or none), and the identity of the confirmer. Quality here is not speed through the close queue. Quality is that no account is zeroed while a pending credit or live mandate remains, and that empty packs were empty in the sources, not in the model.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first