How to Handle Tax on Platform Wallet Interest: FDIC Pass-Through and Income Reporting

---

What to Report When Platform Wallets Earn Interest#

Treat this as two separate decisions from day one: FDIC custodial-account insurance mechanics and IRS income-reporting obligations. They can interact operationally, but they are not the same determination. If you combine them too early, you create avoidable design risk.

Separate the insurance question from the reporting question#

Start with the FDIC side. Ask whether the records at the FDIC-insured depository institution (IDI) can preserve beneficial owners' and depositors' insurance entitlement. The cited FDIC proposed rule notice points to custodial-account recordkeeping, including custodial deposit accounts with transactional features, so insurance determinations and claim payments can happen quickly if an IDI fails. Checkpoint: can your bank program and ledger show who owned each balance, and when, clearly enough to support an insurance determination?

Lock architecture and ownership boundaries before assigning reporting#

Choose structure first, then reporting. Define who holds the account, who is the beneficial owner of wallet balances, where accrual happens, and who controls corrections for each event type. Checkpoint: for funding, accrual, payout, and reversal, can you name the owner of record and the controller of the event? If not, reporting ownership is still premature.

Keep digital-asset reporting logic separate from fiat wallet-interest logic#

If your platform also supports digital assets, split that path explicitly. Form 1099-DA is scoped to proceeds from certain digital asset transactions, including sales, exchanges, or other dispositions, not every wallet-related tax scenario.

Operational timing matters in the cited guidance. Transactions starting in 2025 may begin producing Form 1099-DA for some taxpayers in early 2026. "Some" is doing real work here, so do not treat digital-asset proceeds reporting as the default path for fiat wallet-interest features.

Build an evidence pack before launch#

Before launch, make sure your evidence pack can support both insurance and reporting decisions:

• Wallet ownership and balance-attribution records tied to ledger events
• Reconciliation-ready records for relevant reporting flows
• For digital-asset proceeds reporting, records that reconcile to transaction records, exchange statements, and wallet activity

A common failure mode is a proceeds or reporting mismatch with tax-return amounts, which may prompt IRS follow-up inquiries.

By the end, you should have three outputs: a clear architecture decision, a defensible evidence pack, and a launch checklist aligned across product, payments ops, finance, and compliance.

For a step-by-step walkthrough, see How to Handle a Tax Audit When Your Income is Paid Through Deel or Remote.

Separate the insurance decision from the tax decision#

Keep this split in the PRD from day one: deposit-insurance analysis and IRS income-reporting analysis are different decisions, and treating them as one creates preventable build risk. Treat FDIC deposit-insurance requirements as insurance scope, not IRS instructions on who receives an income form.

Anchor each question to the right authority#

Use one working rule in design reviews:

The current FDIC proposal signal is custodial-account recordkeeping for IDIs that offer custodial accounts with transactional features, aimed at helping the FDIC promptly make insurance determinations if a bank fails. That does not assign tax reporting ownership.

Keep two explicit decision tracks in the PRD#

Give insurance and tax separate rows, owners, and requirements. On the insurance track, capture custodial account setup, bank recordkeeping, and evidence needed for an FDIC insurance determination. On the tax track, capture broker-scope assumptions, Form W-9 collection, Form 1099-DA ownership, reconciliation controls, and correction ownership.

Verification checkpoint: each PRD requirement should map to either FDIC authority or IRS authority, not both in one justification line.

Block the shortcut before build starts#

The usual shortcut is assuming the insurance beneficial owner is automatically the tax reporting recipient. In practice, that is where teams misassign document ownership, exception handling, and corrections.

Set a launch gate: do not build reporting logic until product, finance, and counsel can name both answers separately: insurance entitlement under the bank structure, and reporting responsibility under IRS rules. If either answer is still "TBD," the feature is not launch-ready.

Gather prerequisites and the evidence pack before design starts#

Build the evidence pack before design work starts, or assumptions will harden into product behavior. The standard is simple: each insurance or tax statement in the PRD should map to a named authority, a dated document, and an owner.

Build one source packet and tag every claim by authority#

Start with one shared packet that includes bank or program terms, wallet ledger behavior notes, customer-facing product language, and current tax assumptions from counsel. Tag each claim to its lane: Federal Deposit Insurance Corporation (FDIC) for deposit-insurance questions and Internal Revenue Service (IRS) for reporting questions.

Do not accept unsupported lines such as "bank partner says" as final support. If pass-through treatment is part of the design, include Pass-through Deposit Insurance Coverage and relevant 12 C.F.R. Part 330 references, and record the snapshot date. For example, the eCFR notes content up to date as of 4/02/2026, and Title 12 was last amended 4/01/2026.

Also record the interpretation boundary in the packet. eCFR is authoritative for reference but unofficial, and OFR staff do not answer document-interpretation questions.

Keep product and legal references in one decision file#

Use one decision file so product, finance, and counsel are not working from different versions. At minimum, include current bank-side terms, wallet product documentation, the regulatory references above, and the IRS guidance or memo counsel is using.

Make party roles explicit. Your platform may not be an FDIC-insured bank, and that affects how coverage and reporting ownership are described. If the file does not clearly identify the insured depository institution, recordkeeping owner, and reporting decision owner, pause scope decisions until it does.

Prepare operational artifacts before locking design choices#

Draft candidate artifacts before final design commitments: account-title format notes, beneficial-owner data fields, reconciliation extracts, and change-approval ownership. You are not finalizing implementation here; you are proving the decision can be supported operationally.

Use a traceability check. Can you follow one sample wallet balance from UI display to ledger record to reconciliation extract without manual guesswork? If not, keep coverage and reporting statements provisional.

Treat data quality as a launch risk early. In digital-asset reporting workflows, common failure modes include inconsistent documentation, incomplete transaction data, and limited third-party verification.

Document unknowns and gate build commitments on counsel review#

List unresolved points as open items, not assumptions. For example, the exact IRS classification for wallet interest, or whether any product branch touches digital assets where Form 1099-DA could apply only to certain transactions.

For each unknown, assign an owner, the source needed to resolve it, and a due date. If digital assets are in scope, note the timing and scope limits already described in guidance. Some taxpayers may first receive Form 1099-DA in early 2026 for 2025 activity, and for 2025 it is described as gross-proceeds reporting only.

Keep design exploratory until counsel has reviewed the unknowns list and source packet, and the team has marked which statements are settled versus provisional.

If wallet interest could expand your 1099 or W-8 reporting scope, see Creator Platform Tax Reporting for 1099 and W-8 Expansion Decisions.

Choose wallet account structure and coverage path#

Choose the wallet structure your team can support with evidence, not the one that sounds strongest in marketing. If you cannot maintain reliable beneficiary attribution and reconciliation evidence, keep pass-through coverage language provisional.

Compare structure options by production evidence burden#

Pass-through Deposit Insurance Coverage is not created by structure alone. The practical question is which setup your records can support under stress. Use this as an operating screen, not a legal conclusion.

Check the design against FDIC recordkeeping direction#

The FDIC notice dated October 2, 2024 describes proposed stronger recordkeeping for custodial deposit accounts with transactional features. The same notice says scope is limited to IDIs offering those accounts and that are not specifically exempted, so treat applicability as a program-specific checkpoint.

The operational implication is direct. Record quality affects how quickly deposit-insurance determinations and claim payments can be made. Test your structure by tracing one sample balance from customer display to ledger record to beneficial-owner record to reconciliation output to the relevant custodial account bucket, without manual reconstruction.

Apply bank-program constraints before making coverage statements#

Before making any coverage statement, document in writing the program constraints that actually control it: the insured depository institution, account treatment, and reconciliation deliverables. If those constraints are unclear, coverage language should stay provisional.

Avoid broad coverage statements across partners, entities, or markets unless each bank program's terms support them.

A public comment letter on the proposal also argues for supervision across the BaaS supply chain and highlights risk when bank-customer connections are indirect. Whether or not you adopt that full position, the operational takeaway is useful. As distance from the bank increases, your records can carry more of the trust burden.

If those wallet balances are held in more than one currency, see How to Handle Currency Gain and Loss Reporting for a Multi-Currency Platform.

Map money movement to reporting ownership#

Map reporting ownership at the event level before you build statements or tax logic. For each wallet event, assign both a reporting owner for IRS analysis and a control owner, meaning the party that can prove, correct, and explain what happened.

Trace each money event in sequence#

Start with the event chain: funding, wallet accrual, conversion, payout, and reversal. Then assign ownership before any document-generation workflow.

For each event, record:

1. What changed economically
2. Who owns reporting review
3. Which ledger is the system of record
4. Who owns corrections and exception handling

If ownership only works through manual reconstruction, the map is not launch-ready.

Keep fiat wallet activity separate from digital asset reporting lanes#

Treat fiat wallet activity and digital asset activity as separate branches. In mixed catalogs, this is where reporting logic gets misrouted.

Form 1099-DA is described as tied to digital asset sales or exchanges, with issuance described as starting January 1, 2025, and with issuers described to include brokers, digital trading platforms, payment processors, and hosted wallet providers. That does not turn every wallet event into a 1099-DA event. Funding, fiat accrual, payout, or reversal should not be routed into a digital-asset reporting path unless the event actually qualifies as a digital asset sale or exchange.

This separation can also reduce control risk. Intermediaries can collect more data than is strictly necessary to move funds, and loose event boundaries can make reporting pipelines harder to review and correct.

Build one responsibility matrix across parties#

Once the event map is clear, put the parties in one responsibility matrix so ownership does not drift across teams. This matrix is an operating control, not a legal conclusion about which party must issue a specific IRS form.

Gate launch on clear ownership and exception paths#

Do not launch until every event has:

• A named system of record
• An internal approver for corrections
• A tested exception-handling path

At minimum, test failure cases such as failed funding, late reversal, and payout-status mismatch. Platform-money failure modes include losses and operational breakdowns, so ownership has to hold up under reconciliation and user disputes, not just in happy-path flows.

For the broader platform reporting rules that may sit alongside this issue, see Digital Platform Reporting for Online Marketplaces: MRDP, DAC7, and UK HMRC Duties.

Handle digital asset rails as a separate branch#

If your program includes cryptocurrency or non-fungible tokens (NFTs), split that lane from fiat wallet interest at design time. Reporting triggers, records, and correction paths can differ, so one generic "wallet activity" bucket can misroute events.

Split the event model before you build statements#

Build a separate event catalog for digital-asset activity instead of layering it onto the fiat wallet ledger later. Keep funding, fiat accrual, payout, and reversal in the fiat branch unless an event is actually a sale, exchange, or other disposition of cryptocurrency or NFTs.

Form 1099-DA is described as an information return for proceeds from certain digital-asset transactions, not a universal form for all wallet activity. A practical readiness check is simple: test real or sample user journeys and confirm each digital-asset event can be classified from the ledger record alone.

Apply Form 1099-DA only when the transaction and your role fit#

Use Form 1099-DA only where the transaction type and your role match counsel's documented broker information-reporting interpretation. Keep your internal labels aligned across the PRD, tax memo, and engineering spec so teams map the same events the same way.

Lock in two constraints early:

• For 2025 activity, Form 1099-DA is described as gross proceeds only, without required cost basis or transaction-level adjustments
• Not all taxpayers will receive Form 1099-DA. Some may receive it in early 2026 for 2025 activity

If your team assumes every crypto-adjacent user gets this form, you can over-collect data and over-scope support.

Document the interpretation and reconcile reported amounts#

Documentation and reconciliation are launch gates for this branch. Your evidence pack should include the event map, role map across parties, and the exact reconciliation logic for reported proceeds.

Reported amounts should reconcile to transaction records, exchange statements, and wallet activity. If reported proceeds do not match your records or return amounts, IRS follow-up inquiries may result. If role scope is still unclear, pause automation until counsel's interpretation is finalized. Related: How to Handle Tax on US Partnership Income as an Expat.

Build the reporting data model and controls in the stack#

Build for traceability first, then exports. Your stack should let you prove what happened, who it belongs to, and how it flowed from request to reporting output.

Define a traceable event record#

Start with a consistent event record that can survive audits, corrections, and reruns. As a product design baseline, include a stable event ID and beneficial owner attribution, then add the other fields your legal and compliance teams require (for example legal entity, accrual source, jurisdiction tags, and document lineage to the internal memo or spec and export batch).

The FDIC has issued a proposed rule to strengthen IDI recordkeeping for custodial deposit accounts with transactional features. The proposal scope is limited to IDIs offering those custodial accounts with transactional features that are not specifically exempted. Its stated goal is preserving beneficial owners' and depositors' entitlement to federal deposit insurance protections and supporting prompt determinations if an IDI fails. Treat this as a design signal for strong beneficiary attribution and record quality, not as final law.

Preserve one immutable trail from request to export#

Keep one end-to-end trail from API request to ledger posting to reporting export. If those systems drift into separate histories, reconciliation and corrections become fragile.

Prefer append-only records with linked correction events instead of in-place edits. For any exported row, your team should be able to trace directly back to the originating request and ledger event.

Gate edits and reruns so retries do not duplicate reportable events#

Separate reliability retries from economic events. Add control gates so reruns regenerate from approved ledger state and batch version instead of creating new reportable entries.

A practical checkpoint is simple: run the same job twice in staging and confirm event counts, owner counts, and reportable totals do not change.

Protect tax-workflow PII by design#

Protect tax-workflow PII with the same discipline you apply to money movement as an internal control choice, not as a requirement specified in the FDIC proposal excerpt. Use masked views by default and tightly scoped access for full tax-form and identity records where your policy requires it. Keep document storage controls strict, and retain only the references needed for reconciliation in event records.

Also verify legal text against an official legal edition before you encode requirements into production controls, because FederalRegister.gov XML is informational and not itself the official legal edition.

Set compliance handoffs and review cadence#

Once your event model is traceable, ownership is often the next failure point. Assign named owners for interpretation and correction paths early, or legal, tax, finance, and engineering can each assume someone else owns the hard calls.

Assign separate named owners for interpretation and production#

Set three named owners: legal or compliance interpretation, IRS reporting interpretation, and production operations. Keep them coordinated, but do not make engineering the final authority on rule meaning, and do not leave operations handling live corrections without a clear approver.

Your responsibility sheet should show who approves interpretation, who authorizes reporting corrections, and who executes production reruns and corrected outputs. Legal or compliance decides what the rule means, engineering implements approved logic, and operations runs the live queue, exception routing, and evidence capture.

Run one exception drill and name the signer at each step. If you cannot clearly identify who approves interpretation, who authorizes correction, and who notifies finance, ownership is still blended.

Separate Form 8938 review from FBAR review#

Treat Form 8938 and FinCEN Form 114 (FBAR) as separate review tracks. Form 8938 instructions distinguish them and note that filing Form 8938 does not remove FBAR obligations when FBAR is otherwise required.

For Form 8938, keep operational checks concrete:

• Confirm whether there is an income tax return filing requirement, since Form 8938 is not required when no return is required for the year
• If in scope, ensure filing is attached to the annual return and filed by that return's due date, including extensions
• Preserve the structured account-summary data needed for form fields such as counts and maximum values for foreign deposit and custodial accounts

Avoid threshold shortcuts. IRS materials reference that certain U.S. taxpayers report specified foreign financial assets when aggregate value exceeds $50,000, but that is not a universal product rule for every filer profile.

For document control, store the exact IRS materials used in approval and record the freshness checkpoint in your memo. The IRS About Form 8938 page shows a last reviewed date of 31-Mar-2026.

Gate release on correction ownership, not engineering readiness#

If reporting-correction ownership is unclear, pause release even if the ledger is stable and exports pass staging.

When a reported value changes, you need a named chain for interpretation, related review, output regeneration, and final sign-off. Without that chain, launch governance is incomplete.

Make go or no-go depend on one correction drill. Run a mock post-close adjustment, route approvals, regenerate the affected artifact, and confirm finance receives the updated evidence pack with named sign-off. If the drill stalls, fix handoffs before launch.

Common failure modes and recovery actions#

Once ownership is clear, treat failure handling as a release gate. In a bank-fintech arrangement, three issues are stop-ship defects: unsupported pass-through coverage claims, one-form tax routing assumptions, and any mismatch between wallet UI balances and ledger exports.

Roll back coverage claims when evidence is thin#

If you are using pass-through deposit insurance language but cannot produce clear ownership and bank-record evidence on demand, pull the claim back until controls catch up. Do not treat a legal citation by itself as proof, and do not present a definitive FDIC coverage outcome on its own.

Use one dated evidence pack as your checkpoint for a sample balance, plus the exact memo version used for approval. If that memo relies on FederalRegister.gov text, verify against the official edition or the linked govinfo PDF before treating it as authoritative legal text. Weak proof here creates the kind of bank-customer disconnect that increases partnership risk.

Fix event classification before tax reporting outputs#

If wallet activity is being forced into a single tax-reporting path, assume the mapping is too broad and reclassify events first. The grounding here does not establish that one IRS form applies across all wallet flows.

Start at the event level: separate funding, accrual, conversion, payout, and reversal, then rerun interpretation review for each class. Verify with a side-by-side export that shows old versus corrected classification, approver sign-off, and which downstream reporting artifacts must be regenerated.

Freeze new accrual logic until balances reconcile#

When wallet UI balances and ledger exports do not match, pause new accrual work until the records prove out. A cleaner front end does not offset weak ledger control.

Require two restart proofs: repeatable reconciliation for a defined period and an exception workflow with named investigation, approval, and evidence-storage owners. Accept the tradeoff early: slower roadmap, cleaner records, and fewer correction cycles later.

Related reading: Does Your Non-EU Marketplace Owe DAC7 Tax Reporting in Europe?.

Run launch decision checkpoints before go-live#

Do not launch because the build is complete. Launch only when legal scope, operational controls, and customer language align.

Approve one memo that separates FDIC and IRS scope when both apply#

Use one legal-position memo approved by tax and compliance leads, not scattered notes across tickets or docs. If both FDIC and IRS questions are in scope, make the boundary explicit instead of relying on product behavior. Do not let product logic act as a legal conclusion on its own. Legal terms set the boundary, and implementation follows.

Test support, corrections, and audit evidence under stress#

Run support scripts, correction workflows, and audit exports through both normal and exception scenarios before go-live. Release only when support can explain the feature consistently, corrections have clear ownership, and records can be reconstructed end to end.

For sensitive actions, require dual-control approvals and verify an immutable audit trail that shows who approved, when, and what changed.

Tighten customer language until every claim is defensible#

Customer-facing copy should describe conditions and limits, not guarantees. Avoid absolute coverage or reporting promises when outcomes depend on legal interpretation and operating conditions.

Final checkpoint: every public claim should map back to the approved memo, the tested operational path, and the records you can actually produce after launch.

For related context, see Making Tax Digital for Income Tax and UK Platform Operators: Confirmed Rules and Open Scope Questions.

If your blockers are implementation details such as ownership mapping, idempotent retries, and audit exports, use the Gruv docs to turn this checklist into build tickets.

Final takeaway and copy-paste launch checklist#

Lock architecture and ownership before you debate tax forms. Decide how funds are structured with your bank partner and what records you can maintain, then assign IRS reporting by event type, not by label.

Confirm the wallet structure in writing#

Confirm the wallet structure with the bank partner in writing and map it to the records you keep per user. If you cannot identify the exact account setup and user-attribution fields in your ledger, you are not ready to make FDIC pass-through coverage statements.

Verification point: your evidence pack should include bank program terms, wallet-ledger behavior, and the fields or exports used for user-level attribution. Red flag: if support is only a slide deck or sales email, pause launch claims.

Set legal boundaries for the FDIC citations#

Set legal boundaries for 12 C.F.R. § 330.5 and 12 C.F.R. § 330.7, and avoid filling gaps with thin sourcing. The source guidance here does not support specific eligibility criteria under those sections, so counsel should document what those rules do and do not cover for your program.

Operator check: source hygiene matters. The cited eCFR page is authoritative but unofficial, and in this research set it is Title 12 Part 1005 (Regulation E), not an FDIC pass-through section. If Part 1005 is being used to justify FDIC coverage design, stop and correct the source.

Assign reporting and correction ownership event by event#

Assign reporting ownership and correction ownership event by event. Funding, accrual, conversion, payout, reversal, and statement generation should each have a clear owner across the platform, bank, and any provider.

Verification point: for every event, name the system of record, approver, and correction export path. Failure mode: statement generation has an owner, but corrected reporting after reversals or fixes does not.

Separate digital-asset flows before launch#

Separate digital-asset flows from fiat wallet-interest flows before launch. Form 1099-DA covers proceeds from certain digital-asset broker transactions.

If your product facilitates digital-asset trades for US customers and counsel confirms broker-scope applicability, plan for Form 1099-DA and Form W-9 collection starting January 1, 2025. For 2025 activity, grounded sources describe gross-proceeds reporting only, with some recipients getting forms in early 2026 during the 2026 filing season.

Reconcile reported proceeds to transaction records, exchange statements, and wallet activity. Mismatches can trigger IRS follow-up inquiries.

Validate one end-to-end audit trail#

Validate one end-to-end audit trail from request to ledger to export. You need a clear chain showing who initiated the event, what posted, what changed, and what left the system for reporting or statements.

This is usually where execution risk shows up. If retries, backfills, or manual edits can duplicate reportable events, pause launch until reruns are clean and behavior is idempotent.

Keep launch messaging aligned to the real program#

Keep launch messaging aligned to the program you actually run. Customer copy should reflect real account structure, scope, and availability, not broad promises that all balances are insured or all payouts share one tax treatment.

If classification is unresolved, keep the feature behind internal controls and keep claims out of public copy until documentation is settled.

• Confirm wallet structure decision and user-attribution records with your bank partner
• Confirm legal interpretation boundaries for 12 C.F.R. § 330.5 and 12 C.F.R. § 330.7
• Confirm event-by-event reporting ownership and correction ownership
• Confirm whether any flow is truly in digital assets scope and whether Form 1099-DA applies
• Confirm audit trail completeness from request to ledger to export
• Confirm launch messaging reflects real constraints and program availability

Before launch, confirm market/program fit for your wallet structure and reporting-control model by talking with Gruv. ---