Two fictional demonstrations show how records can become a profile and why an SME may need visibility of downstream use. Each link depends on the stated information, access and matching conditions.
Follow the supporting record.
A payment record can describe when someone bought, how much they spent and which merchant took payment. Where a suitable customer or order reference connects it to a CRM record, those details can become a purchase history. Move the slider to see how much of an example history is linked.
Combining payment records with customer, order or product context can turn separate receipts into total spend, purchase frequency, last-purchase date and product-category summaries. An email address or customer reference may connect the history to an identifiable person. Categories and preferences require supporting context; a payment amount alone does not reveal them.
That richer history can support commercial segmentation or targeting. Trace the purpose, recipients, lawful basis, transparency and access permissions for that use. This diagram uses payment and merchant metadata. Internal fraud-prevention signals are addressed separately in the data-journey explanation.
Illustrative matching scenario. The 100 invented records set the scale of this teaching illustration; the slider’s matching counts are invented. Linking requires available fields, a suitable join and a configured integration. Identification depends on the reference or combination of attributes and the receiving system’s matching information.
Official documentation: customer references and merchant metadata ↗ ·
Explore the reporting & CRM path →FilmPass asks whether an SME can be exposed twice: first through a profile of its own ticket-stock purchases, then through information about the customers it brings to the supplier’s products. This example shows the mechanism using invented records. It distinguishes commercial exposure from the legal responsibility for each use of personal data.
100 codes · £600 stock purchase
Account references connect the SME’s order dates, quantities, spend and product mix. Repeated orders can reveal purchasing frequency and demand patterns. An identifiable owner or employee contact may also be associated with that business history.
40 customer purchases in this example
The SME acquires customers, sells tickets and handles service queries. A tagged code can preserve a link back to a stock batch if the downstream system can access the batch mapping.
If a supplier or connected competing business can use both histories, it may gain intelligence about the SME’s stock demand and the customers the SME paid to acquire. The SME has paid for the stock and developed the customer relationship, while another ecosystem may gain data for segmentation, offers or targeting.
This is a potential two-sided exposure to examine in a real system. A batch tag establishes provenance only where the mapping is available; identifying an individual customer requires additional information. The example shows the SME’s stock expenditure and customer-acquisition work alongside the information available for commercial reuse.
The SME can face customer questions, complaint-handling costs and duties for its own processing while having limited visibility of downstream reuse. Legal responsibility must be traced to each organisation’s actual role and decisions.
A supplier or recipient deciding to use personal data for its own purposes can itself be a controller for that processing. Responsibility is assessed for the SME, supplier and recipients according to their decisions and processing activities. Supplier terms and privacy notices should be compared with the actual data flows, purpose decisions and access arrangements.
Compare the stock invoice and batch allocation with the onward sale or redemption records, customer-reference mappings, CRM fields, recipient table, access logs and policies in force at the relevant dates. Ask whether the supplier can distinguish its own direct members from customers originating with independent SMEs, employers or other partners, and how that distinction survives later enrichment.
Fraud-related information can be repurposed for marketing through a result, a report or a derived attribute. The original device or activity signal does not have to reach the CRM for its output to influence who receives an offer.
Follow the chain: capture → result → match → new attribute → commercial action. The important change is what the information is used to decide.
Payment checking, reporting, data matching and campaign segmentation each have a familiar explanation. Put them together and a security-related result can become a commercial judgement about a customer. Reviewing each product separately can miss that change.
Examine the combined output: what does the resulting profile reveal, who can use it, and which decisions does it influence? The gap to investigate lies between the stated purpose at collection and the actual use after the records have been joined.
| Information layer | Examples | What to establish |
|---|---|---|
| Transaction and supplied identity | Amount, time, merchant/account reference; name, email, billing or shipping details where supplied. | Which fields were submitted, by whom, and for which transaction? |
| Device and activity indicators | IP address and browser/device details where collected; approximate location may be inferred from IP. Activity indicators can include mouse activity and time spent on pages. | Which script collected them, on which pages, and with what session scope? An IP-based location is not precise GPS location. |
| Authentication information | Relevant browser, device and transaction fields used in a 3DS authentication. | Which fields were required or optional for that version and flow? |
| Calculated or evaluated outputs | Available risk scores, rule decisions, evaluated attributes and authentication outcomes. | Which outputs are visible in a dashboard, report, API or export, and to which account? |
| Additional plugin records | Order items, invoice references, reviews, redemption events or independently collected site activity. | Which system collected these separately, and which keys permit a match? |
A risk result condenses information into a value or decision. Joined to an order reference, it can be attached to a customer. A data team can then combine it with purchase frequency, invoice items, review feedback or redemption records to create a new attribute. That attribute can travel onward while the original signal stays in the fraud system.
Example setup: a team can read a payment review outcome and order reference, join them to its customer and order tables, and write a segment into a CRM. This is a constructed demonstration of secondary use.
order_104 has an outcome requiring review.order_104 to customer_27.offer_group = restricted.customer_27 using that attribute. The marketing system receives the segment, while the raw fraud telemetry remains elsewhere.The purpose changes at steps 3–5: information used to assess payment risk now influences marketing eligibility. A changed field name can obscure that origin. A review outcome also carries uncertainty; treating it as an established fact about the person can compound the harm.
| Route | What moves or changes? | Record that reveals the route |
|---|---|---|
| Report or dashboard → recorded result | A visible risk result or summary becomes an input to another analysis. | Report columns, visible identifiers, saved extracts and destination tables. |
| Calculated field → customer segment | A transformation converts results and order history into a customer-linked category. | Source fields, join keys, transformation logic and CRM field mapping. |
| Decision → commercial outcome | A rule changes an offer or audience. The receiving system may get only the final eligibility label. | Rule inputs, decision logs and campaign inclusion or exclusion criteria. |
| Parallel plugin → joined profile | Separately collected activity, invoice, review or redemption records are linked to payment results. | Plugin events, matching references, warehouse joins and the resulting profile. |
This addresses the tool’s function. It leaves a different question: does a result from that tool become an input to marketing elsewhere?
The scope matters. Does “the data” include scores, evaluated attributes, reports, inferred labels and decisions—or only the original inputs? Trace those outputs through the receiving systems.
Stripe’s advanced fraud detection documentation says its device/activity risk-factor data is limited to fraud and security use and is not supplied to advertisers. Its Radar reporting guide separately describes risk scores, rule decisions and evaluated attributes in Sigma or Data Pipeline, alongside other business data.
Those statements concern different layers. A restriction on raw risk factors does not describe the full downstream use of accessible reporting outputs. To answer that question, follow the actual report fields, customer joins, derived labels and destination rules. The worked example above demonstrates that later transformation.
Fraud prevention is essential. Marketing reuse requires its own examination. A fraud-prevention justification does not automatically extend to commercial profiling. Renaming a field, deriving a label or moving it through an intermediary does not remove the need for a lawful, fair and transparent purpose.
Ask: which security-related inputs or results influence the customer profile, the audience selection or the offer—and where is that use explained?
Separate the collected inputs, accessible outputs and independently collected plugin records. Identify the account, field and date for each route. Any “150+” count needs a specified source and version; it cannot stand in for a field inventory. The example uses an accessible output, not access to the processor’s internal telemetry. Public documentation describes capabilities and stated limits; implementation records establish a particular data flow.
WORKED EXAMPLE · TWO USES OF THE SAME CONNECTED TOOLS
A payment check, an invoice, a review and a redemption event can become inputs to one customer profile. Compare the two views to see how a security-related result can be carried into a commercial decision.
Read the complete route: source field → matching key → transformation → CRM attribute → campaign action. Dashed side connections add review, redemption or enrichment records. The visible effect can sit several systems away from the original collection.
The storefront collects order details. A checkout integration requests payment; an invoice plugin uses order information. The processor can retain additional fraud information internally. These are separate records with different holders.
Configured connectors can copy accessible fields into a warehouse. Matching can use suitable customer, order or invoice references; cross-supplier references require an actual mapping. External demographic data can add segments or estimates, not certain facts about a person.
A further import or sync can update a CRM. Marketing tools can use selected fields for segments or messages. Ask who chose those fields, which organisation can see them and what justifies that particular use.
Existing storefront identifiers, reports, connectors and CRM tools supply much of the machinery for a linked profile. A data team adds joins and transformation rules. The commercial value comes from the combined picture: which customers to target, which offers to show and which behaviour to predict.
This lowers the engineering needed to create a new commercial use. It also makes the integration itself a critical point of examination: who chose the combined purpose, what did people understand, and which fields now affect their treatment? Each product’s description answers only part of that question.
Explore the value of linked data →
Compare the collection notice with the executed queries, field mappings and campaign rules. That comparison shows whether the stated purpose follows the information through the whole chain.
A review integration adds rating, text and date. Where its business API includes an order reference, that reference can connect the feedback to a purchase and customer history.
A model can turn that joined feedback into an inferred interest, dissatisfaction or repeat-purchase attribute. The interpretation is newly created by the analysis: the reviewer supplied feedback, while the system creates a profile used for a further decision. Ask which inference is stored and which action depends on it.
The warehouse brings source tables together and calculates new fields. A Snowflake-type platform may hold the primary tables in one region, replicas in another, and return query results to an analyst elsewhere. Those are three distinct routes to follow.
Follow configured replication, remote query access and downstream exports separately. “Stored in the UK” describes a storage location; the full route also includes who receives results, where they access them and what they do next. Identify the receiving entities and relevant transfer arrangements.
Ask for: the primary region; replica destinations; service-account permissions; remote access locations; export destinations; matched review fields; and the origin and intended use of any inferred intent label.
The reporting arrow is a practical route out of the payment context. The linked Stripe guide describes selected fraud-related fields in reporting and warehouse analysis. Once a result sits beside customer and order tables, a further query can turn it into an attribute used by another system.
Trace that next step: the query, its join keys, the derived field and the destination. A policy about the original risk-factor data does not map those transformations.
The question to follow: which fraud-related fields reached the warehouse, what were they joined with, and did they subsequently influence CRM segments, messages or decisions?
Ask for the map behind the policy: source field → receiving system → matching rule → derived field → use → responsible organisation. A statement about one product cannot explain every configured integration around it.
Who should answer which part? →
These sources document the component capabilities. The worked example connects them to show a secondary-use mechanism; trace a real configuration through the records listed above.
For historical analysis, use the account schema and relevant version. The linked Stripe guide dates Radar Rule Attributes history from April 2023. Inputs held internally and fields exposed to an account must be listed separately.
An SME can keep its business plan private while individual purchases and sales leave records with other organisations. Joining accessible records can reveal parts of that plan without anyone receiving the plan itself.
FICTIONAL STOCK AND RESALE EXAMPLE · NO REAL CUSTOMER OR COMPANY RECORDS
Start with the source holders: payment infrastructure supplies transaction records; invoices supply products and quantities; sales and redemption systems add downstream events. The wider picture emerges when a participant can join those sources.
Map the platform, analyst, service accounts and recipients that can read the joined tables. The decisive question is who can use the combined information—not simply which brand appears on each separate tool.
If a recipient competes with the SME, the joined picture could guide targeted offers, supplier negotiations or approaches to important resale channels. The SME’s commercial strategy can become more legible without it ever handing over a business plan. Examine the recipient’s access and subsequent use of the information.
Orders and transactions supply the relationship graph. Matched fraud-related outputs can add another layer of classification. The commercial information advantage comes from the combination of records and the analysis applied to them.
Ask: who can combine our purchase and resale records; which entity/customer/product references connect them; what profiles or derived tables are created; and can someone with a competing commercial interest access or use the results?
Why joined business information matters →
This teaching graph uses the five invented rows above. The joined view gives one analyst access to all five records and matching references. Product quantities come from order/invoice records.
The CMA source discusses general competition risks from algorithms and commercially sensitive business information. It provides context for the access-and-use questions illustrated here.