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 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.

Government-issued photo ID of the requester (driver’s license or passport).
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
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).

-- 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 = '<user_...>';

-- KBV: what institutions did they connect?
SELECT source, institution_name, account_name, account_type, balance,
       last_synced_at
FROM account_details
WHERE clerk_id = '<user_...>'
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):

Users → search the deceased user’s clerk_id → open profile
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)
Set the new email as primary
Delete the old email on the account
Multi-factor authentication → remove all methods
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:

SELECT clerk_id, phone_number, has_mfa, sms_opt_in, updated_at
FROM all_users
WHERE clerk_id = '<user_...>';

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:

UPDATE all_users
SET phone_number = NULL,
    has_mfa = false,
    updated_at = NOW()
WHERE clerk_id = '<user_...>'
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:

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.
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.
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.

First reply, asking for documents

Hi <name>,

I'm really sorry about your <relationship, e.g. "mom">. Happy to help
you get into <her/his> 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 <her/his>
   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 <she/he> signed up
   with, and the names of a couple of banks or brokerages <she/he>
   had connected

Once I've verified everything I'll delete the images from our
inbox, so nothing sensitive lingers.

Take care of yourself,
<your name>
Silvia

After verification, account moved

Hi <name>,

Everything checked out. I've moved <her/his> account over to
<new email>.

To sign in:

1. Go to [cfosilvia.com/sign-in](https://www.cfosilvia.com/sign-in)
2. Enter <new email>
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 <her/his> old phone has been turned off.

A few things to know once you're in:

<optional bullets: name the institutions <she/he> 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,
<your name>
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. Once a system is in place, entries follow this shape:

Date: <YYYY-MM-DD>
Deceased user: <first + last name> (clerk_id <user_...>)
Requester: <first + last name> (email, relationship to deceased,
            clerk_id if they already have a Silvia account)
Documents received:
  - Requester's photo ID: <yes / no + details>
  - Proof of death: <death certificate / obituary link / etc.>
  - Estate standing: <Letters Testamentary / Surrogate doc /
                     EIN letter / none>
KBV: <what they claimed vs. what matched, e.g. "6/6 named
      institutions matched">
Actions taken:
  - Clerk: <what was changed>
  - Supabase: <what was changed>
  - Data export: <yes / no>
Approved by: <your name / founder if escalated>

This is your paper trail if another family member ever disputes what happened.

Auth plumbing: ../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.

Product Guide

Account

Help

Deceased user access

Deceased user account access

Why this is delicate

Verification bar

Documents to request

KBV against the Silvia account

Red flags that require escalation

Look up the user

What to actually give them

Option A: Transfer the account (recommended for ongoing estate work)

Option B: Data export + close the account

Verify Supabase sync

Reply templates

First reply, asking for documents

After verification, account moved

Log the incident

​Deceased user account access

​Why this is delicate

​Verification bar

​Documents to request

​KBV against the Silvia account

​Red flags that require escalation

​Look up the user

​What to actually give them

​Option A: Transfer the account (recommended for ongoing estate work)

​Option B: Data export + close the account

​Verify Supabase sync

​Reply templates

​First reply, asking for documents

​After verification, account moved

​Log the incident

​Related engineering context

Deceased user account access

Why this is delicate

Verification bar

Documents to request

KBV against the Silvia account

Red flags that require escalation

Look up the user

What to actually give them

Option A: Transfer the account (recommended for ongoing estate work)

Option B: Data export + close the account

Verify Supabase sync

Reply templates

First reply, asking for documents

After verification, account moved

Log the incident

Related engineering context