Privacy & Email Marketing Preferences

1Problem & who it's for

Privacy Preferences. Before this work there was exactly one place to set them — an older standalone form, reached from the bank's Privacy page and worded in ways customers found ambiguous. Behind the login, in online banking or the native app, there was nothing. The form also asked every customer for a name, phone number and mailing address, whatever they wanted to change.

Email Marketing Preferences. This was already its own product, under Profile & Settings, reaching roughly 30 million email contacts — customers, prospects and employees. Each brand, from co-brand card partners to the bank's wealth-management and investment brands, has its own opt-in and opt-out choices, and brands are onboarded and retired continuously, so the journeys keep changing. It stayed a separate product; the work here was expanding and modernising it, not merging it.

Four groups carry the cost when this goes wrong:

• Customers who can't manage their choices where they actually bank, or can't tell what each choice means.
• Customer service and branch staff, who handle the requests that arrive by phone and in person instead, applying them as manual overrides.
• Marketing, which needs reliable preference data in its own systems to know which customers and prospects it may contact.
• Compliance and audit, who need to show what a customer chose, and when.

2Evidence & inputs

• The regulations themselves. Working with risk, privacy, compliance and legal, I translated GLBA, TCPA, FCRA, CALFIPA and CAN-SPAM requirements into concrete product requirements: what has to be captured, how long it has to be kept, and what proof of a customer's choice has to look like for an auditor.
• What each request actually needs. The FCC's do-not-call rule asks a business to record the subscriber's name, if given, and telephone number, and to honour the request within ten business days. Our form demanded a mailing address before it would accept one.
• The old form. Which wording customers misread, and which choices they couldn't tell apart — the starting point for a clearer, unambiguous design.
• Where the data has to land. Each choice has to reach the core banking system, the customer-profile platform, the preference data store and the enterprise data platform, and marketing reads it from there. I mapped what each system needs and when.
• API contracts. I read the Swagger contracts with the API and QA teams so the API requirements I wrote were complete and matched what was actually exposed.
• Operational signals and analytics: manual-override volume, calls and branch visits about preferences, and — after launch — Tableau dashboards and product analytics, which informed the usability changes behind a 25% improvement in feature adoption.

3Workflow, controls & guardrails

A customer sets a preference on the public website, in online banking, on mobile web or in the native app — all the same micro-frontend. The platform captures the choice with an audit record and delivers it to the core banking system, the customer-profile platform, the preference data store and the enterprise data platform. Marketing then reads the result to decide whether a customer or prospect can be contacted; that decision stays with marketing, and the platform's job is to make sure it is made on the right data.

• The failure mode designed against: a choice that reaches one system and not another, so marketing acts on stale data.
• Ask only for what a request needs. A do-not-call request takes a phone number, not an address.
• Never overwrite on an ambiguous match. On the public site, the bank identifies the person from what they type. When that matches more than one customer, extra checks narrow it down; if it still isn't one clear match, the request is saved as a prospect's and no existing customer record is touched.
• Audit traceability was a requirement from day one, defined with risk, privacy and legal, not bolted on after the build.
• Monitoring: Splunk dashboards on API performance, built by engineering and tracked by me alongside the product metrics, plus Kibana monitoring of the public-site (prospect) flows across test, UAT and production.
• What "good" meant: product OKRs tied to adoption, compliance SLA adherence and operational error reduction, reviewed through sprint velocity dashboards and quarterly business reviews.

A diagram of the approach, not a product screen. The real artefacts are the client's and stay confidential.

4Options considered

Decision 1 — how to reach every channel

Decision 2 — how to honour "do not call"

5Decision, trade-offs & non-goals

Decision criteria. Backlog items were prioritised on regulatory obligation, business value and technical dependency, in that combination, rather than on any one alone.

Trade-offs accepted.

• Shipping the Do-Not-Call page on today's architecture means call and mail stay coupled in the back end until phase two. We accepted a temporary seam to remove the compliance risk now.
• A slower-feeling cadence each sprint, because tech debt — API versioning, legacy preference migration — shared capacity with features, in exchange for avoiding a debt cliff later.
• A longer rollout, sequenced by channel readiness rather than build order: customer service, branch operations and compliance communications each needed different lead time for training, call-centre scripts and sign-off on customer-facing copy.

Non-goals.

• Deciding who marketing may contact. The platform delivers the customer's choice; marketing applies it.
• Merging Privacy and Email Marketing Preferences into one product. They stay separate product areas with their own journeys.
• A do-not-call page in signed-in channels, where the bank already holds the customer's details.

What's next. Phase two decouples call and mail preferences in the back end and moves preference data off the legacy system of record onto a modern distributed database. Further out — and still only at the idea stage — we're exploring whether AI agents could take a new preference and draft its full delivery package from the Preference Delivery Framework: the stories, acceptance criteria and checklists, ready for the team to review.

6What I delivered

• A revamped public-website form, clearer and unambiguous
• One micro-frontend bringing privacy preferences to online banking, mobile web and the native app, where none existed before
• A standalone Do-Not-Call page that needs only a phone number
• Phased launches: the public site in September 2025, then online banking and the native app in November 2025, followed by a landing page that routes people to sign in or to verify who they are
• An FCRA experience-and-transaction sharing preference customers can now manage digitally, and email notifications confirming preference changes
• Ongoing Email Marketing Preferences releases: wealth-management, investment and co-brand partner brands onboarded and retired, with refreshed brand themes and simpler opt-in and opt-out journeys
• A Preference Delivery Framework, which I built from scratch after my product manager proposed the idea: a reusable package of story templates — discovery and compliance, UX, API, events and monitoring, QA and release — so each new preference (California consent, FCRA affiliate sharing and the rest of the roadmap) follows the same checklist instead of starting from scratch
• 300+ user stories with detailed acceptance criteria, and the integration requirements for every downstream system — core banking, customer profile, preference store and data platform
• Product OKRs, channel-specific GTM plans and training milestones, and a prioritised tech-debt backlog

7Outcome & metrics

• 19M+ users impacted
• 60% reduction in manual overrides through workflow optimization
• ~$750K operational savings annually
• NPS +8 points improvement
• 25% feature adoption improvement via usability enhancements informed by Tableau/product analytics
• 30% faster release cycles through better backlog refinement · 20% defect reduction through UAT/SIT coordination
• 94% Epics Predictability · 100% User Story Predictability · 92% test coverage · 56% post-launch feature completion rate
• 100% API uptime and ~18 avg daily sessions since the September 2025 go-live
• ~450K investment customers covered by compliant (CAN-SPAM) unsubscribe once the investment brand was onboarded
• 4 channels from one build, delivered by a ~12–15-person scrum team

Do-Not-Call page (launched 2026 — too early for results). Measurement plan: requests completed; time to honour each request against the ten-business-day limit; and do-not-call requests that still arrive by phone or in branches, which should fall.

Regulatory, legal and reputational risk. For a bank of this size, the cost of getting consent wrong is rarely the fix — it is the exposure. Under the TCPA, a customer who receives repeated marketing calls after asking not to be called can sue for up to $500 per call, and up to three times that if the violation is found to be wilful; across millions of customers, that becomes class-action scale. Honouring every choice the same way in every system, with an audit trail, and accepting do-not-call requests without demanding extra personal data, lowers that exposure — along with the regulatory scrutiny and headline risk that follow a consent failure at a top-10 bank.

Figures as recorded at the time. Client-identifying detail is withheld under NDA. TCPA damages per 47 U.S.C. § 227(c)(5).

8Retrospective

The highest-leverage change wasn't a better form — it was putting the choice where customers already bank. Once signed-in customers could set their own preferences, requests stopped needing a call or a branch visit to become a manual override.

The Do-Not-Call release taught me to ask, for every request, what does this actually need? A shared form quietly asks everyone for everything. Splitting out the one request that needed far less was a small build with an outsized compliance payoff.

What I'd do differently: map every affected team before refinement starts. While we were delivering an FCRA preference change, the team responsible for TCPA wasn't in the room early enough. When they joined, they pointed out that a do-not-call request shouldn't need a mailing address — which is what led to the standalone Do-Not-Call page. The release still shipped, but the dependency surfaced late. Since then, a list of affected teams and stakeholders is part of discovery in our Preference Delivery Framework, not something we find during implementation.