> ## Documentation Index > Fetch the complete documentation index at: https://docs.cfosilvia.com/llms.txt > Use this file to discover all available pages before exploring further. # Deceased user access # Deceased user account access Use this when a family member or estate representative contacts support because a user has died and they need access to that user's Silvia account, usually to help settle the estate. For a **living user** who lost access to their own account, use [`account-access-lockout.md`](./account-access-lockout.md) instead. *** ## Why this is delicate * We hold sensitive financial data (linked bank / brokerage balances, transactions, holdings) so we don't hand over an account without proof. * "Deceased relative" is a classic social-engineering angle, so we verify. * On the other hand: the person contacting us is usually grieving, overwhelmed, and working with lawyers. Our job is to be warm and make our part easy, not add friction. *** ## Verification bar **Not legally required, but strongly recommended.** No US federal law mandates specific documents to release account access after death. RUFADAA (adopted by most states) says the *opposite*: companies aren't required to hand anything over without a court order, but can if they want to, and our Terms of Service govern first. What we actually want is enough evidence to be confident about two things: **the user really died**, and **the person asking is who they say they are and has standing to act for the estate**. ### Documents to request Ask for all of these. Most families can produce them within a day. 1. **Government-issued photo ID of the requester** (driver's license or passport). 2. **Proof the user died**, any of: * Certified or non-certified copy of the death certificate (photo is fine) * Public obituary link with the requester listed as surviving family * Funeral-home program 3. **Standing to act for the estate**, any of: * Court-issued Letters Testamentary or Letters of Administration (a will alone is not enough; it must be probated) * NJ Surrogate paperwork (or the equivalent from other states) showing the person as executor / administrator * IRS letter assigning an EIN to the estate (proves an estate has been formally opened) **Item #3 is required for every transfer or export.** Identity (#1) and KBV establish *who is asking*; #3 establishes *authority to act for the estate*. Account size is not an authorization control, so "small account" is not a waiver. The only allowed exception is a documented, case-by-case sign-off from the founder (or legal, once we have one) after they've reviewed the specific situation in writing. If you're tempted to bend this, escalate; do not use judgment alone. ### KBV against the Silvia account Also ask for two facts they should know about the deceased user's Silvia account. Pick from: * The email the user signed up with * The phone number on the account, if any * The names of at least **two institutions** the user had connected (Chase, Fidelity, Vanguard, etc.) * Approximate signup timeframe (month + year) This is the fraud check. A random person who knows the deceased died won't be able to name the institutions Silvia is connected to. ### Red flags that require escalation * Any hint of a family dispute (other siblings, ex-spouse, contested estate) * Requester's name is not on the obituary and doesn't obviously connect to the user * Requester asks for anything unusual beyond access (wire transfers, changing where money is held, etc.) * The account has significant assets and the documents don't include Letters Testamentary Escalate to the founder / legal before doing anything. *** ## Look up the user You'll need their `clerk_id` (usually the family member will give you the email; find the account from there). ```sql theme={null} -- Confirm the account exists SELECT id, uuid, clerk_id, signup_provider, has_mfa, country, timezone, created_at, onboarding_completed, account_deleted FROM all_users WHERE clerk_id = ''; -- KBV: what institutions did they connect? SELECT source, institution_name, account_name, account_type, balance, last_synced_at FROM account_details WHERE clerk_id = '' ORDER BY institution_name, balance DESC NULLS LAST; ``` Match the requester's KBV claims against the `institution_name` column. Note also what's **stale** vs. **fresh**; you'll want to tell them what to expect. *** ## What to actually give them **Two options**, pick whichever fits their need. ### Option A: Transfer the account (recommended for ongoing estate work) Move the account to an email the requester controls, so they can log in going forward and see current balances as connected accounts sync. **Steps** (Clerk dashboard): 1. Users → search the deceased user's `clerk_id` → open profile 2. **Email addresses** → add the requester's email * If they already have their own Silvia account under their primary email, use the Gmail `+alias` trick: `theirEmail+deceasedName@gmail.com`. Emails still land in their inbox, but Clerk treats it as a separate identity, so both accounts coexist. * Verify the new email (admin bypass, or let them enter the code) 3. Set the new email as **primary** 4. **Delete the old email** on the account 5. **Multi-factor authentication** → remove all methods 6. **Phone numbers** → remove the deceased user's phone (their number could get reassigned by the carrier) The `user.updated` webhook syncs `email`, `phone_number`, and `has_mfa` into `all_users` on its own. Verify with the query below. ### Option B: Data export + close the account Only if they explicitly say they don't need ongoing access and just want a snapshot for probate paperwork. Generate an export of accounts, balances, holdings, and transactions as CSV / PDF and send it to the requester. Then soft-delete the account via the standard account-deletion path. *(Note: as of writing, we don't have a self-serve export flow for support-initiated exports. Escalate to engineering to pull one.)* *** ## Verify Supabase sync After making the Clerk changes, give the webhook \~30 seconds, then check: ```sql theme={null} SELECT clerk_id, phone_number, has_mfa, sms_opt_in, updated_at FROM all_users WHERE clerk_id = ''; ``` A recent `updated_at` tells you the webhook fired and wrote *something*; it does **not** tell you the email specifically changed. `all_users.email` is stored encrypted, so it isn't human-readable in a raw `SELECT`. To confirm the new primary email actually landed, check the Clerk dashboard (source of truth for identity) or decrypt the column with a decrypt helper. For the other Clerk-sourced fields (`phone_number`, `has_mfa`) the values above are directly comparable to Clerk's state. If one looks stale, patch **only that field**; do not blanket-clear the row. The webhook is the source of truth for anything you changed in Clerk; a manual `UPDATE` here is a fallback for the rare case it didn't fire. For example, if you removed the phone and turned off 2FA in Clerk but Supabase still shows the old values, this brings the row back in line with Clerk state: ```sql theme={null} UPDATE all_users SET phone_number = NULL, has_mfa = false, updated_at = NOW() WHERE clerk_id = '' RETURNING clerk_id, phone_number, has_mfa; ``` Do **not** touch `sms_opt_in`. It is Silvia's own SMS-consent state, not sourced from Clerk, and only changes via the explicit opt-in / opt-out flows. If only the email looks stale, patch just that column instead. *** ## Reply templates Warm, human, low-friction. Do not be transactional. **Interim document handling.** Until Silvia has a secure upload channel, verification documents (ID, death certificate, court paperwork) may arrive as email attachments to `support@cfosilvia.com`. When they do: 1. Ask the requester to redact numeric identifiers where reasonable (driver's license number, SSN, EIN). Keep name, DOB, and photo visible; that's what we're actually matching. 2. Handle the request, then delete the message + attachments from the inbox once the incident-log entry is written. Do not forward the attachments to anyone. 3. Never store attachments in a shared drive, chat, or ticket system. This is a workaround, not the intended design; the secure-upload follow-up is tracked in [`README.md`](./README.md#known-limitations--follow-ups). ### First reply, asking for documents ```text theme={null} Hi , I'm really sorry about your . Happy to help you get into account. To move forward I'll need the following. If you can, redact any numbers on the ID (license #, SSN) before sending; name, DOB, and photo are what I actually need to match. 1. A photo of your driver's license (redacted as above) 2. Either a photo of the death certificate or a link to obituary 3. Court paperwork naming you as executor / administrator of the estate (Letters Testamentary, Letters of Administration, a state Surrogate document, or an IRS EIN letter for the estate) 4. Two things that match the account: the email signed up with, and the names of a couple of banks or brokerages had connected Once I've verified everything I'll delete the images from our inbox, so nothing sensitive lingers. Take care of yourself, Silvia ``` ### After verification, account moved ```text theme={null} Hi , Everything checked out. I've moved account over to . To sign in: 1. Go to [cfosilvia.com/sign-in](https://www.cfosilvia.com/sign-in) 2. Enter 3. We'll email you a 6-digit code (it lands in your regular inbox if you used the "+alias" trick) 4. Enter the code and you're in The 2FA that was going to old phone has been turned off. A few things to know once you're in: had connected, call out which of those connections are fresh vs. stale and which will need reconnecting, and flag anything held jointly with another family member so it isn't a surprise. Do **not** put balances or dollar amounts in this email; they'll see the numbers once they sign in.> Let me know if anything looks off. Take care of yourself, Silvia ``` *** ## Log the incident **Before you write anything here, confirm your team has designated one approved system for these records** with defined access, retention, and deletion controls. A deceased-user entry names the deceased user, the requester, verification decisions, and admin actions taken against a real account; it must not live in random channels or personal notes. Until a system is formally designated, escalate to the founder rather than writing an ad-hoc entry. Tracked as a follow-up in [`README.md`](./README.md#known-limitations--follow-ups). Once a system is in place, entries follow this shape: ``` Date: Deceased user: (clerk_id ) Requester: (email, relationship to deceased, clerk_id if they already have a Silvia account) Documents received: - Requester's photo ID: - Proof of death: - Estate standing: KBV: Actions taken: - Clerk: - Supabase: - Data export: Approved by: ``` This is your paper trail if another family member ever disputes what happened. *** ## Related engineering context * Auth plumbing: [`../CLERK-AUTH-ONBOARDING-ROUTING.md`](../CLERK-AUTH-ONBOARDING-ROUTING.md) * The `user.updated` webhook (`app/api/webhooks/clerk/route.ts`) clears `phone_number` when Clerk removes the number and mirrors `two_factor_enabled` into `has_mfa`. Fixture and test coverage live in `app/api/webhooks/clerk/__tests__/user-updated-phone-mfa.test.ts`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.