Estate settlement software, for a bank or credit union, is software that takes a deceased customer’s accounts from the first death notice to a settled estate: it verifies the death, reads each account’s signature card and beneficiary forms, finds federal benefits paid after the death, checks the affidavit or court letters and prepares each payout for a person to approve. The best way to evaluate it is to rerun 30 to 50 estates the bank has already closed and compare what the software proposes with what the bank actually did, account by account. Agreement is expected; the disagreements are the evidence, because each one is either a software error, a past error of the bank’s, or a policy choice nobody wrote down. Botminds’ Deceased Account Processing is offered on exactly that basis, and this guide shows how to run the test on any vendor’s product.
The term is also used for tools that help executors administer a whole estate, from real estate to tax returns. This guide is about the bank’s side only: the deposit accounts, loans and benefit credits a financial institution has to settle. The worked examples come from a fictional credit union and its fictional sample estates; no figure on this page is a measured result at a real institution.
A six-week pilot on closed estates, then on live notices beside the team
- Choose 30 to 50 closed estates; gather the files5 d
- Software reruns every estate from the original documents2 d
- Compare with what the bank did, account by account3 d
- Classify every disagreement by cause6 d
- Fix settings, not answers; rerun the changed estates4 d
- New death notices run in parallel; the team works as usual8 d
- Compare and decide2 d
What does estate settlement software do at a bank?
It does the reading, matching and drafting that fill most of a bereavement desk’s week, and it should leave the decisions that move money to people. A complete product covers six jobs: matching a death notice to the right customer; finding every account, card, loan and recurring payment the customer had; reading the document that decides each account’s destination; finding federal benefits credited after the death and drafting the Treasury certification; checking the legal authority of each payee; and drafting letters.
Each job has a rule behind it that the software must apply exactly. The destination of a joint or payable-on-death account follows the account’s terms; in Virginia, a will cannot override a beneficiary designation (Va. Code § 6.2-608(E)). A small estate is payable only within the state’s limit and after its waiting period, $75,000 and 60 days in Virginia (Va. Code § 64.2-601). A federal benefit credited after the death must be handled under 31 CFR 210, where the bank must certify the day it first knew, actually or constructively, of the death (31 CFR 210.11(b)(2)). Software that gets the reading right and the rule wrong is worse than none, because it is wrong with confidence and at scale.
Why does a demo estate prove so little?
Because the vendor chose it. A demo estate is clean by construction: typed signature cards, one beneficiary form per account, an affidavit within the limit, no withdrawals after the death. Real estates are not. They contain the cards and cases that make the work hard, and those are exactly what a demo leaves out.
A vendor’s demo estate against a replay of your own closed estates
The demo estate: Typed, recent, one form per account.
Your closed estates: Cards from decades ago, handwritten notes, forms re-indexed in a conversion, designations replaced years later.
The demo estate: One of each: joint, payable on death, sole.
Your closed estates: In-trust-for cards, joint cards without a survivorship box, a beneficiary who died before the owner.
The demo estate: A benefit credited and held.
Your closed estates: A benefit withdrawn by a co-owner before anyone knew, a representative payee, a notice that arrived months later.
The demo estate: An affidavit well within the limit.
Your closed estates: An affidavit near the limit, a limit changed between the death and the affidavit, an executor who arrived before the court appointed him.
The demo estate: The vendor’s.
Your closed estates: Yours: what your team decided, signed and paid, and what later turned out to be wrong.
A demo also hides the most important behaviour, which is what the software does when it is unsure. An accuracy figure on clean files says nothing about whether the product stops and asks on a 1979 card it cannot read, or answers anyway. The Treasury’s 2024 report on AI in financial services warns that generative models can produce wrong answers delivered with complete assurance (U.S. Treasury, December 2024), a risk AI hallucination in credit policy citations examines in depth. The replay is designed to surface exactly those moments.
How to evaluate estate settlement software: replay your closed estates
Give the software the original documents of estates the bank has already settled, let it work each one from the death notice to the proposed payouts, and compare its proposals with the bank’s own decisions, line by line. The bank already has the answer key, so the comparison costs reviewer time, not risk: nothing the software proposes is acted on.
Three rules keep the test honest. The software sees only what the bank had at the time: the notice, the documents and the account history, not the bank’s own disposition or later correspondence. Every disagreement is recorded before anyone explains it away. And the bank’s team, not the vendor, decides which side was right, with the document in front of them.
Which closed estates belong in the replay?
A deliberate mix, weighted to the hard cases. Thirty to fifty estates is enough to see each kind of case several times without turning the pilot into a project. Random selection will mostly produce easy joint-account estates; a replay set should be built.
A replay set of 40 closed estates, built to test what goes wrong
| Kind of estate | How many | What it tests |
|---|---|---|
| Joint accounts with right of survivorship only | 6 | That a surviving owner is never frozen, and the retitle is proposed, not a payout |
| Payable on death, several beneficiaries | 6 | Shares, identities, call-backs; at least one beneficiary who is not a customer |
| Payable on death with a replaced designation or a beneficiary who died first | 4 | That the later form is found and the predeceased beneficiary is not paid |
| In-trust-for or other cards older than 1990 | 4 | That old wording is read or, below the threshold, handed to a person |
| Sole accounts under a small-estate affidavit | 6 | The limit and waiting period in force on the date of death, and the affidavit’s required statements |
| Sole accounts under letters testamentary or of administration | 4 | Payment to the estate account only after the court’s appointment |
| A federal benefit after the death, including one withdrawn before notice | 6 | Hold, knowledge date and the withdrawer list for the certification |
| Estates the bank later found it had settled wrongly | 4 | Whether the software would have caught what the team missed |
The last row needs a word. Every bereavement desk has a few estates it would settle differently now: a beneficiary paid who had died first, a benefit released to a survivor, an affidavit accepted a few days early. Including them is uncomfortable and is the only way to find out whether the software would have prevented them. A vendor that objects to that row is telling the bank something.
What should a bank test before buying estate settlement software?
Score each estate on the decisions that carry the bank’s liability, not on how many fields the software extracted. The scorecard below is built from what 31 CFR 210 and state account statutes make the bank answer for.
The scorecard: what to compare on every replayed estate
- Destination of each account
Same payee and amount as the bank, or a disagreement with both readings and the deciding passage.
- The document cited
The same card or designation the bank relied on, or a later one the bank missed.
- The knowledge date
The same date, or an earlier credible source the bank did not log, such as a call or a branch employee’s report.
- Every federal credit after the death
All found, each with what happened to it: held, returned or withdrawn.
- The withdrawer list
Co-owners, everyone authorized to withdraw, everyone who withdrew after the death, as the certification requires.
- Authority for each payee
The affidavit checked against the limit and waiting period in force on the date of death; letters checked for the right person.
- Freezes proposed
Only the deceased’s own card, sole accounts and access; never a surviving joint owner.
- What it did when unsure
Stopped and handed to a person, or answered anyway. Count both.
- Letters
One per person, naming only that reader’s share.
Then classify every disagreement by cause, because the causes, not the count, decide the purchase. Sort each into one of four causes: the software was wrong; the bank was wrong at the time; both readings are defensible and the bank has an unwritten policy; or a document was missing from what the software was given. The first is a reason to doubt the product unless the vendor can show why and fix it in settings. The second is the pilot paying for itself. The third is a policy to write down. The fourth is a finding about the bank’s archive.
What a replayed estate should produce: every account, its document, both readings and the totals
The six weeks, week by week
Weeks one and two are the replay itself. Most of the time goes into gathering files: the death notice, every signature card and designation, the affidavit or letters, the account history from the date of death, and the bank’s own disposition, kept aside. Running the software is the short part; Deceased Account Processing’s agents took 3 minutes 9 seconds on the fictional sample estate once its documents were in. Comparing goes quickly when the software lays its proposals beside the bank’s decisions; it is slow when someone has to rebuild each estate’s answer from memos.
Weeks three and four explain the disagreements. This is where the bank’s policies surface. If the software pays a survivor and the bank always waited for a certified certificate, the fix is a setting, not a new answer. Thresholds, call-back rules, which fields must agree to verify a death and the payout amount that needs a third signature should all be settings the bank changes, with a named approver and a version, and the changed estates rerun.
Weeks five and six put the software beside the live team. New death notices run in parallel; the team settles them as usual and the software’s proposals are compared afterwards. This is where speed shows up honestly, on the bank’s own volumes and documents, and where the team sees whether it trusts what the software hands it.
Reading the result: when to buy, and when to walk away
Decide on the pattern of disagreements, not their number. Three results argue for buying. Every disagreement the software caused can be traced to a setting the bank can change, and rerunning with the setting changed removes it. On every document it could not read with confidence, it stopped and handed the file to a person. And on at least some of the estates the bank knows it settled wrongly, it proposed the right answer, with the document that shows why.
Three results argue for walking away, whatever the overall agreement rate. A single proposed freeze on a surviving joint owner, because it means the product does not apply titling before it acts. A payout proposed to a beneficiary who died before the owner, because the rule is in the statute: in Virginia, payable-on-death money belongs to the beneficiaries “if surviving” (Va. Code § 6.2-608). And a confident answer on a card a person could not read either, because that is the failure the bank cannot see coming in production.
The middle ground is a product that is right but slow to explain itself. If a reviewer cannot see, for each line, which card or form decided it and which passage in it, the bank will spend in review what it saved in reading. The FDIC’s rule that payable-on-death beneficiaries have to appear in the bank’s deposit account records (FDIC, Your Insured Deposits; see FDIC insurance on payable-on-death accounts) is a useful last test: ask the software to show where in the records it found each beneficiary.
What should the vendor hand you, and what stays with the bank?
The vendor should hand the bank a product whose every rule is a setting it can see, whose agents are versioned so a reading can be reproduced later, and whose output cites its documents. The bank keeps the obligations. No regulator has written an AI rule for estate settlement; the GAO found in 2025 that federal financial regulators examine a bank’s AI under the laws, guidance and risk-based examinations they already apply, rather than under new AI rules (GAO-25-107197; what examiners look for in AI audit software).
Third-party guidance points the same way. The banking agencies’ 2023 guidance on third-party relationships is still in force, and their September 2026 proposal to replace it keeps the core principle that relying on a vendor leaves the bank just as responsible for meeting its legal requirements as doing the work itself (proposed guidance, September 15, 2026; 2023 guidance; see the interagency guidance on third-party relationships). The pilot is part of the due diligence that guidance expects, and its scorecard belongs in the vendor file.
Rules the agents apply, each with its source, version and the person who verified it
Where estate settlement software fits, and where it does not
It fits where a bank settles enough estates that the reading, retrieval and drafting are a real queue, where its signature cards and designations are in document imaging the software can read, and where the bank wants every decision traceable. It is strongest on the estates with many accounts, old cards and federal benefits, because those are where a person reading by hand is slowest and most likely to miss something.
It does not make a probate court issue letters faster, shorten a statutory waiting period, or settle a dispute between heirs; those waits remain, and the software’s job there is to make them visible. It does not replace counsel on an unusual estate, such as a contested will or a trust with conflicting terms. And it should not be bought to remove the second officer: the value of two signatures on every payout is that the second person did not prepare it. A bank that settles a handful of estates a month with clean, recent paperwork may find a good written procedure does most of what software would.
For the line between what the agents do and what people decide, what each agent may never do goes agent by agent; the deceased account checklist is a ready-made answer key for the scorecard; and deceased account services compared weighs software against outsourcing the desk. To run the replay on your own estates, start from Deceased Account Processing.
Questions people ask
What are estate settlement solutions for banks?
They are the ways a bank handles deceased customers’ accounts: an in-house desk working by hand, an outside service, or software that reads and drafts while the bank’s staff decide. All three must still apply the same rules, from state account statutes to the Treasury certification for federal benefits paid after a death.
Is deceased account software the same as estate settlement software?
For a bank, largely yes: both describe software that settles a deceased customer’s accounts. The difference is emphasis. Deceased account software usually means the bank’s back-office side; estate settlement software can also mean tools that help executors administer every asset in an estate, which is a different product for a different buyer.
How long should a software pilot take?
About six weeks is enough for a replay of 30 to 50 closed estates, an explanation of every disagreement, and two weeks of parallel running on live notices. A bank with few estates a month may need longer in the parallel phase to see enough new cases of each kind.
What accuracy should estate settlement software reach?
The useful figure is not a percentage of fields read but the number of payouts it would have sent to the wrong person, and what it did when unsure. Deceased Account Processing’s design target is zero payouts to the wrong person, met by deriving every disposition twice and having a second officer release each payout.
Does estate settlement software need access to the core banking system?
To be useful, it needs to read accounts, owners, holds and transactions since the date of death, and document imaging for cards and forms. Writes, such as a hold, a retitle or a payout, should go to the core only after a person approves them, and the replay itself can run on extracted files with no write access at all.