Changing a customer's email must be an identity update, not an account migration. Short answer: keep an immutable account ID, require step-up proof on both addresses, and make the new address earn its way through verification before it becomes a login identifier. That design preserves balances, KYC records, limits, and abuse history while still letting a legitimate user recover access.
I run a one-person SaaS, so my test for auth work is revenue per hour. A flow that is theoretically elegant but creates support tickets is expensive. In fintech, a mistaken merge is worse: it can join two people’s financial histories. The default should be continuity with an explicit, reviewable change event.
The decision matrix for an email-change flow
| Approach | Abuse resistance | User friction | Record integrity | Best fit |
|---|---|---|---|---|
| Replace email after new-address verification | Medium | Low | Strong if account ID is immutable | Normal, authenticated changes |
| Verify old and new addresses plus recent password/MFA | High | Medium | Strongest | Payments, withdrawals, regulated profiles |
| Support-assisted change with identity review | Very high | High | Strong with an audit trail | Lost mailbox, suspected takeover |
| Create a second account and merge later | Low | High | Fragile | Almost never; only with a formal migration process |
The tempting shortcut is to treat the email as the primary key. It works until a user changes jobs, loses a mailbox, or an attacker controls a forwarding rule. Use a random, immutable account_id everywhere money or compliance data is stored. Keep email addresses in a separate, versioned identity table with verified_at, revoked_at, and a unique constraint on active addresses.
One sentence is enough: the address is a credential, not the person.
How can fintech teams change an email address without creating a new account?
Start from an authenticated session, but do not trust session age. Ask for the current password again and, where enabled, a second factor. OWASP recommends reauthentication for sensitive account changes and generic responses that do not reveal whether an account exists. The change request should carry a short-lived, single-use token bound to the account and the intended new address.
The sequence I ship is deliberately boring:
- Create a pending change containing
account_id, old address, normalized new address, an expiry (15 minutes), and an opaque request ID. - Send a confirmation link to the new address. Send a notice to the old address without including secrets or the new address in clear text.
- Verify the link, then require the current password or MFA if the session is stale, the account has a payout method, or the risk score crosses a threshold.
- In one transaction, mark the old identity as historical, insert the verified new identity, and append an audit event. Never rewrite ledger ownership.
- Revoke sessions and recovery tokens according to policy, then require sign-in with the new address.
The transaction boundary matters. If the email row changes but the audit event fails, support cannot explain what happened. If the audit event lands first and the write fails, a replay can look like a second change. An outbox event committed with the identity update gives downstream notifications an idempotent source of truth. Think through the race explicitly: a customer opens the confirmation link in two tabs while a support agent is viewing the same pending request. The first transaction takes the row lock, verifies the token, revokes the old identity, inserts the new one, and consumes the request. The second transaction then sees a consumed token and makes no state change. A retry from the mail client has the same result. If the new address already belongs to another active account, the uniqueness constraint aborts the whole transaction, leaving the original login and ledger untouched; the public response stays generic, while the audit log records a conflict for review. This is more code than assigning user.email, but it is a finite cost that prevents an ambiguous identity merge from becoming a financial incident.
Normalization deserves a written policy. Lowercasing the domain is common; provider-specific tricks such as removing dots or plus tags can collapse distinct mailboxes. Store the original display value for communication, compare a canonical value for uniqueness, and document the exact transformation. Your mileage may vary across enterprise mail systems, so test with real domains before promising aliases.
type PendingEmailChange = {
id: string;
accountId: string;
newEmailCanonical: string;
tokenHash: string;
expiresAt: Date;
};
async function confirmEmailChange(changeId: string, token: string) {
return db.transaction(async (tx) => {
const change = await tx.pendingEmailChange.lockForUpdate(changeId);
if (!change || change.expiresAt <= new Date()) throw new Error("expired change");
if (!constantTimeEqual(hash(token), change.tokenHash)) throw new Error("invalid token");
await tx.emailIdentity.revokeActive(change.accountId);
await tx.emailIdentity.insert({
accountId: change.accountId,
emailCanonical: change.newEmailCanonical,
verifiedAt: new Date()
});
await tx.auditOutbox.insert({
accountId: change.accountId,
event: "email_changed",
requestId: change.id
});
await tx.pendingEmailChange.consume(change.id);
});
}
The code is intentionally generic. The important properties are locking, token hashing, expiry, and an atomic audit record. Error text can be detailed in internal logs, but the public endpoint should return the same shape for an unknown address, an expired token, and a used token.
What should be logged and rate-limited when an address changes?
Abuse resistance is a system, not a CAPTCHA checkbox. Rate-limit requests per account, source network, device signal, and destination domain, with separate budgets for starting a change and sending another message. A fintech account that requests 30 emails in five minutes may be under attack even if every request has a valid password.
Log an immutable event with actor, account ID, request ID, risk decision, factor used, and outcome. Do not log the token, full addresses, password, or recovery answers. Alert on bursts, repeated failures, a new address followed by a payout change, and changes made from a novel device. Keep notification delivery asynchronous so a mail provider timeout cannot leave the database half-updated.
I once assumed a verified new mailbox was enough. Then I modeled a stolen, still-active session: the attacker could redirect notices and race a withdrawal. The fix was a fresh factor for high-risk accounts and a short cooling period before sensitive money movement. It added friction. It also made the decision explainable to support.
Where common identity products fit, and where they stop
Managed identity services can reduce the amount of password and token code a solo team owns. Auth0, Amazon Cognito, and Clerk all document email verification and account-management primitives, but the surrounding financial invariants remain yours: immutable account IDs, ledger joins, payout holds, and audit retention. Their hosted flows differ in customization, migration tooling, and how much session policy you control; compare those boundaries against your threat model rather than a feature-count chart.
The catch is that a vendor-managed profile is not a compliance record. If your provider cannot express a two-address confirmation, a cooling period, or an exportable audit event, keep that orchestration in your service. Conversely, building password storage and recovery from scratch is not suitable when you cannot staff security review; stick with a managed identity layer and keep your domain data keyed by your own account ID.
A ship-week checklist for continuity
Before release, test the awkward paths: an expired link, a replayed link, an address already owned by another account, two browser tabs racing, a bounced message, and a password reset during a pending change. Property-based tests can assert that one canonical email maps to at most one active account. An integration test should prove the ledger's account_id is unchanged after the identity transaction.
Roll out behind a flag. Measure completion rate, median time to verify, support contacts, and suspicious changes per 1,000 active accounts. Review the first week of audit events manually. Ship weekly, outsource the undifferentiated mail delivery where it makes sense, and spend your own hours on the policy decisions that protect customer funds.
There is no universal friction setting. I'm not sure a risk score alone will age well as mailbox attacks change; revisit thresholds with incident data and regulatory counsel. The durable rule is simpler: verify control, preserve identity, record the decision, and make high-risk money actions wait.
Top comments (0)