Quick answer: deposit insurance is not calculated by looking at each bank account separately and asking whether its balance is below a headline limit. A failed-bank determination system must identify the real owner of each balance, classify the legal ownership category, combine accounts that belong together, separate accounts that qualify for different coverage, trace custodial or brokered funds through to underlying owners where pass-through requirements are met, handle trusts and joint accounts correctly, incorporate pending transactions and holds, and produce an auditable insured-versus-uninsured result. The mathematics is mostly aggregation, partitioning and graph-like ownership resolution; the hard part is making the data and legal definitions line up quickly enough to work during a bank failure.

The question is not “How many accounts exist?” It is “Which balances belong to the same owner, in the same legal capacity, at the same failed bank?”

Page role and boundary: eduKateSG already owns the broad civilisation-level question of why deposit insurance exists and how it can reduce bank-run incentives. This Bukit Timah Tutor page owns the narrower mathematics/computation problem: how a deposit-insurance determination engine reconstructs ownership and calculates insured balances after a bank failure. It is educational, jurisdiction-specific examples are clearly labelled, and it is not advice about where any individual should keep money.

Why this is an algorithmic problem

Deposit insurance looks simple when reduced to one number. In practice the system must solve several linked data problems:

identity resolution: which records refer to the same depositor?
ownership classification: in what legal right and capacity are the funds held?
aggregation: which balances must be added together before applying a limit?
decomposition: which pooled balances belong to multiple beneficial owners?
exception handling: which accounts need documents or manual review?
transaction-state reconstruction: what was the balance at the legally relevant failure time?
auditability: can every insured amount be traced back to records and rules?

In the United States, the FDIC’s current Part 370 framework requires covered institutions—generally insured depository institutions with two million or more deposit accounts—to maintain systems capable of supporting timely deposit-insurance determination if the institution fails. See the FDIC’s Part 370 recordkeeping resources and alternative-recordkeeping processing guidance.

1. The first mathematical object is not an account—it is an ownership claim

Suppose one person has three accounts at the same failed bank: S$100,000 savings, S$120,000 current account and S$80,000 certificate of deposit. If all three are held by that person in the same ownership category, a correct engine generally aggregates them before applying the category’s insurance rule. Product labels do not create separate coverage merely because the money sits in different account types.

The FDIC states this directly in its general principles of insurance coverage: deposits held by the same depositor in the same ownership category at the same insured institution are combined for insurance purposes.

A useful data representation is therefore:

Claim = (bank, beneficial owner, ownership category, balance, evidence, status).

The algorithm groups claims by the keys that legally determine common coverage rather than by account number alone.

2. The core aggregation formula

Let B_i,c be depositor i’s balances in ownership category c at one failed bank. A simplified category total is:

A_i,c = Σ B_i,c,k

over every account k that belongs in that same category. If L_c is the applicable coverage limit under the relevant rules, then the teaching-version insured amount is:

I_i,c = min(A_i,c, L_c)

and uninsured amount:

U_i,c = max(A_i,c − L_c, 0).

Real rules are more complicated because some categories contain multiple owners, beneficiaries or participant interests. The point is that the headline limit is applied only after the engine has correctly constructed the legal aggregation unit.

3. Ownership categories are classification rules

Under current US FDIC rules, coverage depends on the legal right and capacity in which deposits are held. The FDIC’s public materials include categories such as single accounts, joint accounts, certain retirement accounts, trust accounts, employee benefit plan accounts, corporation/partnership/unincorporated-association accounts and government accounts. See Understanding Deposit Insurance.

Algorithmically, classification can be represented as:

category = f(account title, ownership records, legal form, beneficiaries, signatures/usage evidence, fiduciary indicators, supporting documents).

This is not ordinary machine-learning classification where an 80% probability may be good enough. The output changes a legal entitlement. Ambiguous records must therefore be routed to a pending/manual-review state rather than silently assigned to the most likely class.

4. Joint accounts require owner decomposition

A joint account has one account balance but multiple ownership interests. If a S$400,000 joint account is owned equally by two people, the computational system first decomposes the account into two S$200,000 ownership claims before combining each person’s share with that person’s other qualifying joint-account interests at the same bank.

Under US rules, evidence is required for an account to qualify for joint-account treatment. FDIC Part 370 guidance also explains how accounts that need additional review can be placed into a pending state, while records that fail the joint-account requirements can revert to another ownership treatment. See the FDIC Part 370 Q&A.

The important algorithmic lesson is:

one bank account row can generate several beneficial-owner rows.

5. Pass-through insurance turns custody into a graph problem

Now consider a brokerage, fintech, payroll provider or other custodian that places money into one pooled bank account for many customers. The bank’s ledger may show one named account holder, while economic ownership belongs to hundreds or thousands of underlying principals.

FDIC pass-through coverage requires conditions including actual ownership by the principals, account records that indicate the custodial/agency nature of the relationship, and records identifying the principals and their ownership interests. See Pass-through Deposit Insurance Coverage.

The structure can be represented as an ownership graph:

Bank pooled account → first-tier custodian → sub-custodian → beneficial owner → ownership category.

The FDIC’s Deposit Broker’s Processing Guide explicitly illustrates multi-tier ownership trees and the documentation needed to trace balances through them. A missing edge in that graph can delay or change the determination.

6. Conservation of money is the first reconciliation test

If a pooled custodial account contains S$10 million and the submitted beneficial-owner file contains only S$9.7 million of interests, the engine should not simply proceed. The ownership decomposition has failed a conservation test.

For a pooled account p:

bank ledger balance_p = Σ beneficial interests_p,j + explained adjustments.

Differences can arise from pending transactions, fees, accrued interest, timing, suspense items or bad data. The reconciliation difference must be explained before a high-confidence payout calculation can be claimed.

This connects directly to How Banks Reconcile Transactions: the same conservation principle appears here under much greater time pressure.

7. Trust accounts add a beneficiary dimension

Trust accounts show why a general “one depositor, one limit” rule is computationally inadequate. Coverage can depend on trust owners and eligible beneficiaries under the governing jurisdiction’s rules.

In the United States, trust-account rules changed effective 1 April 2024. The FDIC now applies a simplified trust-account framework and states that the maximum coverage for a trust owner with five or more beneficiaries is US$1.25 million per owner for all trust deposits at the same bank, subject to the rule’s requirements. See the current FDIC employee guide.

A robust system therefore versions its rules by effective date. Re-running an old bank-failure dataset under today’s trust rule can generate the wrong historical answer.

8. Rule versioning is part of correctness

The determination engine should store something like:

(jurisdiction, rule version, effective date, failure date, ownership category logic).

This matters whenever coverage limits, trust rules, product eligibility or recordkeeping requirements change. A result is not reproducible if the system cannot say which rule set produced it.

9. Pending transactions make the failure timestamp important

A bank can fail while cheques, card settlements, ACH payments, interest accruals, internal sweeps or other entries are pending. The operational system therefore needs a legally defined balance state and treatment for pending transactions.

The determination problem is closer to reconstructing a ledger snapshot than reading yesterday’s closing balance:

determination balance = posted ledger + included pending items − excluded/reversed items ± rule-defined adjustments.

Every adjustment needs provenance. Otherwise two teams can compute two different “correct” balances from the same institution.

10. Pending-file states are safer than false certainty

Some accounts cannot be determined immediately because records are incomplete. A good system needs an explicit pending state such as:

missing beneficiary data;
ambiguous joint ownership;
unreconciled pooled-account total;
custodian ownership file not yet received;
document required to establish trust or fiduciary status;
conflicting identity records.

FDIC Part 370 includes pending-file concepts for accounts requiring additional information or review. This is a broader mathematical lesson: unknown is a valid system state. Forcing an uncertain record into “insured” or “uninsured” can be worse than temporarily marking it unresolved.

11. Identity resolution must avoid both false merges and false splits

If “Mohamed A. Rahman” and “M A Rahman” are the same depositor but the system treats them as different people, their balances may escape required aggregation. That is a false split. If two genuinely different people with similar names are merged, coverage can be understated. That is a false merge.

The problem links to How Banks Match Customer Identities. Deposit-insurance processing adds a stronger control: ambiguous identity matches may need human/legal review because the cost of an identity error directly changes the insurance calculation.

12. A miniature determination example

Imagine a simplified jurisdiction with a S$250,000 limit per depositor per ownership category at one bank. Mei has:

S$180,000 single-name savings;
S$120,000 single-name term deposit;
a 50% interest in a S$300,000 qualifying joint account with Arjun.

The single-name deposits aggregate to S$300,000. Simplified insured single-category amount = S$250,000; uninsured = S$50,000. Mei’s joint interest is S$150,000 and is evaluated under the separate joint category, assuming the rule’s conditions are met.

The computational lesson is the order:

decompose ownership;
classify category;
aggregate matching claims;
apply the category rule;
reconcile totals.

Applying the limit to each raw account first would produce the wrong result.

13. Payout and resolution are different layers

Once insured amounts are determined, the resolution authority can make insured funds available through mechanisms such as transferring deposits to another institution, operating a bridge bank, or paying insured depositors directly depending on the resolution structure.

The FDIC explains these mechanisms on its Payment to Depositors page. During the 2023 Silicon Valley Bank resolution, the FDIC used a bridge-bank structure and transferred deposits under a systemic-risk determination. That extraordinary treatment should not be confused with the ordinary insurance-calculation rules: resolution action and baseline insured amount are separate objects.

14. Alternatives to full automatic determination

Not every account should be processed through one end-to-end automatic rule engine. A practical architecture can combine:

deterministic rules for clean standard accounts;
graph decomposition for custodial/pass-through structures;
document-supported calculation for trusts and unusual ownership;
pending queues for missing or conflicting data;
manual adjudication for legally ambiguous cases;
post-calculation sampling and reconciliation.

The alternative to automation is not “no algorithm.” It is a hybrid algorithm whose stop conditions are explicit.

15. Failure modes

Account-by-account insurance. Limits are applied before required aggregation.
Product-category confusion. Savings, current and term accounts are treated as separate legal ownership categories.
False identity split. One depositor is represented by several customer records.
False identity merge. Two depositors are collapsed into one.
Broken pass-through chain. Pooled accounts cannot be reconciled to beneficial owners.
Rule-version drift. Today’s legal logic is applied to a past failure date.
Silent ambiguity. Missing trust/joint/custodial evidence is guessed rather than marked pending.
Balance-time mismatch. Pending transactions are included inconsistently.
Conservation failure. Sum of beneficial-owner claims does not equal the bank’s pooled balance.
Resolution conflation. Emergency protection of uninsured deposits is mistaken for the ordinary insurance rule.

16. Diagnostics and falsifiers

Do all same-owner/same-category accounts aggregate to one determination unit?
Can every pooled balance be reconciled to beneficial-owner interests?
How many determinations depend on fuzzy identity matching?
How many accounts remain pending because required ownership evidence is missing?
Can the calculation be rerun from raw records and reproduce the same result?
Does the system preserve the exact rule version effective on the failure date?
What percentage of uninsured balances changes if identity linkage is challenged?
Which account types generate the highest reconciliation error?

Suppose someone claims, “Every account below US$250,000 is fully insured.” A falsifier is a depositor holding several same-category accounts at one failed US bank whose aggregated balance exceeds the applicable category limit. The raw account balance is not the legal aggregation unit.

17. Verification and update triggers

reconcile total deposit liabilities to the general ledger;
reconcile every pooled account to its sub-ledger or ownership file;
run synthetic bank-failure tests with known expected results;
independently recalculate samples across each ownership category;
test identity matching with deliberately similar and multilingual names;
version rules whenever limits or ownership requirements change;
re-test after core-banking, broker/custodian or trust-record system changes;
measure time-to-determination as well as numerical accuracy.

Connections across the finance-and-banking algorithms lane

Risk-based deposit-insurance assessments — how insurance funding is charged to banks; a different job from calculating depositor entitlements.
Bank resolution waterfalls — what happens to other claims once the institution fails.
Customer identity matching — prevents false aggregation and false separation.
Transaction reconciliation — the conservation and exception logic underlying failed-bank balance reconstruction.

Research anchors

The deeper lesson

Deposit-insurance determination is a graph-and-ledger problem disguised as a headline coverage limit. The system must identify who owns money, in what legal capacity, through which custodial chain, at what timestamp and under which rule version. Only then can a limit be applied. Strong systems preserve uncertainty instead of guessing, reconcile every decomposition back to the ledger, and make the final insured amount reproducible from evidence.

Educational note: Coverage rules differ by jurisdiction and change over time. The numerical examples here are for mathematical explanation, not personalised deposit-placement advice or legal interpretation.

Small Group Tutorials

How Deposit-Insurance Payout Algorithms Determine Who Is Insured: Ownership Categories, Aggregation, Pass-Through Records and Failed-Bank Data