The rule is about resolvability
Part 370 applies to an insured depository institution with at least two million deposit accounts for two consecutive quarters, as well as an institution that voluntarily elects coverage. A newly covered institution generally has three years to comply. The rule requires recordkeeping and information-technology capabilities that allow deposit insurance to be calculated after failure; it does not increase the statutory insurance limit. [1]
The eCFR page reviewed September 30 was current through September 25, 2026. The page notes that Title 12 was last amended September 14, but that statement does not by itself establish that Part 370 changed on that date. The detailed obligations below come from the operative text displayed for Part 370. [1]
The 24-hour capability is more than a file export
A covered institution’s system must be able to calculate coverage for each deposit account within 24 hours after the FDIC is appointed receiver. It must also generate specified output records, restrict access while a determination is pending and debit uninsured amounts. For records maintained under permitted alternatives, the system must perform after the FDIC supplies the additional information. [1]
That design creates at least four separate tests: can the bank identify the account holder and beneficial owners; can it assign the correct ownership category; can it calculate coverage consistently; and can production controls apply holds and debits to the same accounts? A successful data extract does not prove that the end-to-end resolution process works.
Partner and omnibus accounts need executable data delivery
For certain transactional accounts where the bank does not maintain all information needed for a calculation, section 370.5 requires steps reasonably calculated to obtain the data. At minimum, the bank must make a good-faith effort to contract for compatible delivery to the FDIC and give the account holder a written disclosure and an opportunity to validate delivery capability. The rule lists specific account categories for which those steps are not required. [1]
For a fintech or program relationship, a contract that says records will be available is only the first control. A practical test should reconstruct beneficial-owner identifiers, balances, ownership codes and pending reasons from the systems that will exist during disruption. Validate field formats, duplicate resolution, cut-off times and secure delivery without relying on one employee or a partner dashboard that may be unavailable.
Annual certification and FDIC testing create two evidence layers
A covered institution must certify compliance and submit a deposit-insurance coverage summary report on or before its compliance date and annually afterward. The chief executive officer or chief operating officer signs after due inquiry. The report includes account holders and deposits by ownership category, fully insured and uninsured amounts, and accounts the system cannot calculate from current records. [1]
The FDIC can periodically test compliance, generally no more often than a three-year cycle after the initial timing condition. A material change to the system, deposit operations or financial condition can support testing at another time. Internal annual certification and regulator testing therefore answer different questions: management attests to the capability every year, while the FDIC independently exercises it periodically. [1]
Scroll horizontally to see all columns.
| Evidence layer | Frequency or trigger | What it should establish |
|---|---|---|
| Management certification | At compliance date and annually | Required capabilities were implemented and tested during the prior 12 months |
| Coverage summary report | With the certification | Account and deposit exposure by ownership category, including unresolved calculations |
| FDIC test | Periodic; ordinarily no more frequent than a three-year cycle | The institution can perform the required functions with regulator participation |
| Additional testing | Material system, deposit-operation or financial-condition change | The capability remains effective after consequential change |
Merger relief is bounded
The rule states that an instance of noncompliance occurring as the direct result of a merger is deemed not to constitute a violation for 24 months after the merger becomes effective. This is not a general two-year release from Part 370 and does not erase deposit-insurance, data, consumer-access or other operational obligations. [1]
A merger plan should identify which account and ownership records differ, how customer identifiers will be reconciled, when systems become authoritative and what the combined institution cannot yet calculate. Waiting until core conversion to assess those gaps can turn a bounded transition into an untested resolution dependency.
Data lineage and an illustrative failure
Consider a customer with $150,000 in an individual account and $150,000 in a qualifying joint account. The categories can receive separate coverage if ownership requirements are met and records support the classification. If a program bank stores the customer name in one system, beneficiary status in another and ledger balances in a partner file, stale identifiers or duplicate records can prevent timely aggregation. This example omits other accounts and exceptions. [1][3]
Institutions need a golden-source mapping among deposit core, subledger, partner program, ownership codes, transaction history and legal documentation. Tests should include missing tax identifiers, duplicate people, omnibus accounts, closed accounts, accrued interest and data received from third parties. Reconciliation must prove both completeness and the ability to produce an accurate depositor-level view.
A practical control map
The rule permits exemptions, exceptions and release requests in defined circumstances. Those mechanisms require specific evidence and FDIC action; a bank should not infer relief from delay or operational difficulty. [1]
Scroll horizontally to see all columns.
| Control | Evidence | Failure mode |
|---|---|---|
| Coverage calculation | Reproducible depositor and ownership aggregation | Correct balances assigned to the wrong owner or category |
| Pending records | Reason codes and tested collection procedures | Unresolved accounts are hidden inside a successful total |
| Partner delivery | Validated format, secure transfer and recovery exercise | A contractual promise cannot be executed during disruption |
| Access restriction | Account-level hold and debit test tied to the calculation | The bank calculates correctly but cannot operationalize the result |
| Change management | Regression test after conversion, merger or new program | A previously compliant design fails on the new data model |
Costs, limits and evidence that would change the view
Part 370 can require substantial systems work, data governance and recurring testing, especially for banks with many program managers or nontraditional ownership structures. More detail improves resolution but raises privacy, vendor-management and operational complexity. Useful tests measure retrieval time and exception rates, then reconcile sampled calculations to legal categories rather than merely confirming that a file exported. [1][2]
Part 370 compliance does not guarantee that every depositor is insured, nor does it guarantee a particular resolution outcome. Evidence of repeated unresolved accounts, failed partner deliveries or controls that cannot apply the calculated restriction would weaken confidence. Successful full-cycle tests, declining exception rates and documented change testing would strengthen it. Consumers should use the FDIC’s official coverage guidance for their own accounts. [3]