Single Customer View (SCV): Definition, Regulatory Uses in Banking and Gambling, and How to Build One in a Customer Data Platform (CDP)

A single customer view (SCV) is, in marketing, one unified record of each customer assembled by a customer data platform (CDP) or similar system. In UK regulation the same words mean something narrower: for deposit takers, the Single Customer View is a PRA-mandated file that must reach the FSCS within 24 hours; in gambling, it is a cross-operator harm-prevention scheme, GamProtect. Marketing teams must not conflate them.

Who this is for: data, marketing, compliance and architecture teams at banks, building societies and gambling operators, and anyone asked for "an SCV" without being told which kind. You get the three meanings, what the rules say, how to build a marketing view, how a CDP differs from master data management, and a checklist. Part of the Learn hub.

Single customer view meaning: three different things

The phrase names three unrelated artefacts, and only one is a legal obligation today.

Caution: in regulated contexts "single customer view" has a legal meaning. A marketing profile is not an FSCS file, and gambling harm-prevention flags are not marketing data.

The marketing single customer view

Marketing sources describe an SCV as a unified perspective of an individual customer across touchpoints, combining data from several systems into one profile 1. CDP.com draws a line between the single customer view (one unified record per customer, via unification and identity resolution) and Customer 360 (that record plus enrichment, history, prediction and activation), and says the first must come first; it gives the term no regulatory meaning 2. That split is one vendor's convention, and in practice the terms are used interchangeably.

A single customer view example (illustrative):

The CDP Institute's definition fits this meaning: software that creates and maintains a persistent, unified customer record that other systems can access 3. Architecture is covered in customer data platform architecture and entity design for banks in the customer 360 data model.

FSCS Single Customer View: what UK deposit takers must produce

The rules sit in chapter 12 of the Depositor Protection Part of the PRA Rulebook. A firm must give the FSCS its single customer views and exclusions views within 24 hours of deposits becoming unavailable, and give them to the PRA or FSCS within 24 hours of a request. A new deposit taker must be able to supply them within three months of getting permission. Delivery must be by secure electronic transmission; the firm's system must automatically identify the covered deposit payable to each depositor and flag any part above the coverage level; and the firm must take reasonable steps to keep the data accurate 45. The point is speed: the FSCS pays compensation within seven working days of a failure 6.

What is in the file. The rulebook table has four groups and 51 numbered fields (one now deleted) 4:

• Customer details: names, previous name, National Insurance number, passport number, other national ID, company number, date of birth.
• Contact details: address lines, postcode, country, email, three phone numbers.
• Account details: account number, sort code, IBAN and BIC, product type and name, account holder indicator (for joint accounts), status, exclusion type, recent transactions in the last 24 months, a bank recovery and resolution marking, balance in sterling, currency, exchange rate.
• Aggregate balance: total in sterling and the compensatable amount.

A unique customer identifier must be consistent across the SCV and the exclusions view. The exclusions view lists accounts that fall outside normal payout, using codes for beneficial ownership (BEN), dormant accounts (LEGDOR), legal disputes (LEGDIS) and HM Treasury sanctions (HMTS) 4. The FSCS accepts three layouts: four separate files, two files or one combined file 6.

Elsewhere. The US has a comparable idea under another name: FDIC rules (12 CFR Part 370) require institutions with two million or more deposit accounts to maintain systems that calculate insurance coverage per account, ready within 24 hours of the FDIC being appointed receiver 910.

Single customer view in gambling: GamProtect and the cross-operator idea

In 2020 the Gambling Commission challenged the industry to build a "Single Customer View" so that harm could be spotted across operators, and worked with the Betting and Gaming Council (BGC) and the ICO; the legal basis was cleared with the ICO in 2023 11. A BGC announcement in 2022 said the trial had been delayed by nearly two years over data-sharing concerns 12. The 2023 gambling White Paper said the Commission intended to consult on mandating participation in a cross-operator harm-prevention system, and that the data would never be used for commercial purposes 13.

How GamProtect works. At its launch on 11 September 2024 the Commission described it this way: an operator that closes an account after a customer self-declares a very serious marker of gambling-related health harm shares a flag; other participating operators can see it; no further details about the person are shared. It was live with the four largest operator groups and had identified 5,527 consumers, 88% matched by at least one operator and 66% by at least two. Participation was voluntary, with mandating possible if take-up did not grow, and the Commission hoped to widen the markers 11.

Do not confuse it with:

For an operator's CDP. Keep the internal player view and GamProtect participation separate. Treat flags as harm-prevention data: keep them out of marketing audiences and models, suppress promotions immediately when a flag or closure applies, and log every use. See single customer view for gambling operators and real-time responsible-gambling interventions.

How to build a single customer view

1. Define purpose and consumers. Marketing, service and risk need different views. GDPR purpose limitation and minimisation apply to each 18.
2. Inventory sources, owners and keys. Note which system is authoritative for each attribute.
3. Model the data: party, identifiers, relationships (accounts, products), household or organisation, events, consent, derived attributes.
4. Set an identity policy. Deterministic keys first; probabilistic matching only where error is cheap. See identity resolution explained.
5. Make consent and suppression first-class, enforced at activation, not only stored.
6. Choose latency per use (table below) and test it.
7. Govern it: survivorship rules, lineage, quality measures, retention, access control, a subject-request path.
8. Expose it through APIs, warehouse tables or reverse ETL, with logging.
9. Monitor match rate, completeness, freshness and merge anomalies.

See real-time decisioning for latency budgets.

Where a CDP fits versus MDM

They work together: MDM can supply the authoritative party ID, the CDP adds behaviour and consent, and the "single view" is whatever is served to a given consumer. For all five categories see CDP vs CRM vs DMP vs MDM vs data warehouse, and for fundamentals What is a customer data platform?.

Single customer view checklist

Back to the Learn hub. If you run a bank or a gambling operation and need unified customer data inside your own boundary, with consent enforcement and an audit trail, see the PrivyCDP platform and its pages for financial services and gaming.

This article is general information, not legal advice.