A relative telephones to tell you a customer has died. Walk me through everything your systems have to do from that call onwards.

The event belongs to the person, not to an account

The reason bereavement handling goes wrong in banks is almost always structural. A customer relationship is expressed as a set of accounts, each owned by a product system, and the news arriving on the telephone is a fact about a human being rather than about any one of them. If the only place the fact can be recorded is an account, it will be recorded on the account the caller happened to mention, and every other product will continue behaving as though nothing has happened: a card keeps authorising, a loan keeps demanding, a savings statement arrives addressed to the deceased, and a marketing campaign selects them for a mortgage offer.

So the first design commitment is that the deceased status is an attribute of the party, set once, with an effective date of death that is distinct from the date you were told. Those two dates are both load-bearing and they are usually different by days or weeks. Interest, fee application, and the treatment of transactions that occurred in between are all decided against the date of death, while your own operational obligations run from the date of notification. A system that stores only one of them cannot answer either question correctly.

Notified, verified, and authorised are three different states

Nobody presents a death certificate on a telephone call, so you have to act on an unverified assertion, and refusing to act until documentation arrives is the wrong answer. The obligation that binds immediately is protective: prevent further loss and stop distressing contact. The obligations that require evidence are the ones that move money.

That produces a staged model worth stating explicitly. On notification you record the assertion against the party, suspend outbound contact and marketing, and apply protective restrictions to the instruments most exposed to misuse — cards, digital access, and any standing authority to debit. You do not yet close anything, you do not yet release funds, and you do not tell the caller the balance, because at this point you know nothing about who they are.

On verification, when a death certificate or an official registration record reaches you, the status becomes fact. Debit access is stopped, credit interest and charging are handled according to your policy and the date of death, and the account moves into an estate-administration state that still exists and still accrues but accepts no instruction from the former mandate.

On authority — a grant of probate, letters of administration, or whatever your jurisdiction's equivalent instrument is, or a simplified process your policy allows for small estates — a named personal representative can act. Only now can somebody be told the balance, close the account and receive the funds. Collapsing these three states into one workflow is how banks end up either paying an estate to a stranger or telling a grieving family to come back in six weeks before anyone will even stop the direct debits.

What keeps running unless you stop it

The unglamorous half of this question is the inventory, and it is where an interviewer separates people who have done the work from people describing a state machine. A power of attorney ends on the donor's death, so any attorney who has been operating the account must lose access at the point of verification, and a system that treats an attorney as simply another authorised user will not know to revoke them. Standing orders keep paying out. Direct debit mandates keep letting third parties collect, and each originator has to be told rather than merely blocked, or you will generate a stream of failed collections and arrears letters at the other end. A scheduled overdraft fee will apply. A card on file at a subscription service will keep being presented. An arrears process will keep escalating, and a dunning letter arriving addressed to somebody who has died is the single most complained-about outcome in this whole area.

Each of those needs a decision recorded rather than an accident. The decision is not always "stop": a mortgage on a property still needs its buildings insurance premium paid, and freezing everything indiscriminately can damage the estate you are protecting.

Joint holdings, and why they are the exception

A joint account is the case that breaks a naive design, because in many jurisdictions the survivor's right to the funds continues by survivorship and the account is not part of the estate at all. Freezing it because one party's record now carries a deceased flag deprives a bereaved person of the money they are entitled to use, which is both a service failure and, in the plainest sense, wrong. Your party model therefore has to distinguish sole from joint holdings and apply the deceased status per relationship rather than per account, removing one mandate while leaving the account operable. The same care applies to a business account where the deceased was a signatory rather than the owner, and to a trust or executor account they administered for someone else.

Bereavement is not a closure workflow

The trap in this question is building it as an account-closure feature with a document upload. Closure is the last step and the least important one; almost all of the value and almost all of the harm sits in the propagation. A single notification has to reach every product system, every communication channel, every campaign selection, every collections queue and every third party with a standing authority, and it has to be observable that it did. That means the notification is an event with subscribers and an audit of who consumed it, not a flag on a row in one database that other systems may read if they happen to join to it.

The second-order requirement is reversibility. Notifications are sometimes wrong, occasionally maliciously so, and a mistaken deceased marker that has propagated to a credit reference agency and a bereavement suppression register is genuinely difficult to withdraw. Recording the fact as a stated event with a source and a verification state, rather than overwriting the party record, is what makes the correction tractable. So is knowing every downstream consumer you notified, because you now have to tell all of them the opposite.

Finally, treat the interaction itself as a design constraint. The person on the telephone is dealing with a death and should not have to repeat it to each product line, should not be asked for the certificate more than once, and should not be transferred to a queue that opens with a marketing message. A single case, one set of documents, and a record that the whole organisation can see is the difference between a competent process and eleven separate ones.

Record the death against the person with both dates, propagate it as an event with observable consumers, and keep notified, verified and authorised as separate states - because the protective actions must not wait for paperwork and the money must never move without it.