{ "version": "1.0", "edition": "FilmPass public education", "prepared": "2026-10-31", "scope": "Public education, illustrative mechanisms and public references; private case evidence excluded.", "pages": [ { "id": "https://filmpass.nsstudio.uk/index.html", "title": "Our journey & purpose", "sections": [ { "id": "https://filmpass.nsstudio.uk/index.html#section-1", "heading": "Through the eyes of an SME & consumer.", "text": "OUR BUSINESS. OUR MEMBERS. OUR SEARCH FOR ANSWERS. Through the eyes of an SME & consumer. FilmPass bought corporate cinema ticket stock from two suppliers we understood to be legally separate, for resale to members through benefit arrangements. We paused on 23 December 2024 while seeking answers about those purchases and the possible impact on members. Two legally separate suppliers. One shared CRM? Our concern is whether our suppliers reused payment fraud-prevention data and outputs to enrich profiles and combine records in a shared customer relationship management (CRM) system for commercial gain. Our experience prompted this research into closed user groups, digital commerce and the information generated around a benefit. Paused since 23 December 2024 677 days elapsed as at 31 October 2026 Why we began this research ↗ Understand the technology → Education edition prepared 31 October 2026 · Based on our journey since December 2024 THE SYSTEM, MADE VISIBLE 01 / 06 PURCHASE REDEMPTION ACTIVITY CONTEXT DECISION REPORT RECORD Signals. Decisions. Connections. Explore →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "PURCHASE REDEMPTION ACTIVITY CONTEXT DECISION REPORT RECORD" ] }, { "id": "https://filmpass.nsstudio.uk/index.html#why-we-paused", "heading": "We bought cinema tickets for our members.", "text": "We bought cinema tickets for our members. We understood the tickets to be the product—not our members. Our starting point was practical: an SME buying cinema ticket stock from two suppliers and supplying those tickets to its members. Those members included employees of UK companies, key workers, police and armed-forces personnel. We wanted to understand the commercial relationships and what happened to information as a ticket was bought, supplied and redeemed. Our concern was whether using those tickets could involve collecting, linking or reusing information about people beyond what they would reasonably understand from buying or redeeming a cinema ticket. That question prompted our research: what information is collected, who can use it, for which purposes, and how clearly is that explained? We paused on 23 December 2024 while seeking to understand our supplier transactions and the possible impact on members. That is our account of why this research began. The worked examples explain how information can move between connected systems, acquire new meaning and support further uses. They identify the connections, records and questions needed to examine those processes.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#research-chronology", "heading": "How this research developed.", "text": "How this research developed. Before the pause: we bought corporate cinema ticket stock from two suppliers for our members. 23 December 2024: we paused while seeking explanations about our supplier transactions and the potential impact on members. Following the process: we pursued the available complaint and review routes while researching the systems involved. Private correspondence and procedural records remain separate. Sharing the learning: this educational resource brings together public sources, technical explanations and questions others can use. We continue to follow the relevant processes and will provide updates when appropriate. We will also add further research and worked examples as they are reviewed, with sources and revision dates. 417 recorded events. Our private event log contains 417 recorded events as at 31 October 2026. The log and supporting documents are preserved separately while the relevant processes continue. This public website shares the educational research arising from that journey.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#why-share-this", "heading": "Complex systems should have understandable explanations.", "text": "Complex systems should have understandable explanations. Consumers and SMEs should be able to ask more than “does your policy allow this?” They should be able to understand the information, the route and the decision. Follow the information Separate payment details, merchant records, device signals and later inferences. Ask what was accessible at each step. Follow the purpose Identify why information was collected and whether a later use changes that purpose. A useful system still needs an accountable explanation. Follow the responsibility Identify who made each decision, who can explain it and how a correction reaches the relevant records.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#our-focus", "heading": "From a cinema benefit to a wider understanding.", "text": "From a cinema benefit to a wider understanding. This is a developing educational white-paper website: a place to follow our research and understand systems that are difficult to see from the outside. Our focus is closed user groups: schemes offering benefits to employees, customers or eligible communities. Corporate cinema tickets provide the starting example. The questions extend to eligibility checks, supplier identity, payment processing, redemption, fraud prevention and later commercial use of information. We explain our reasons for asking, show the technical possibilities and identify what records would establish the actual route. Our private evidence bundles and active proceedings remain separate. Explore closed user groups →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#start-learning", "heading": "Choose your starting point.", "text": "Choose your starting point. Research directory Explore this chapter ↗ Closed user groups & benefits Explore this chapter ↗ Public records & research examples Explore this chapter ↗ Follow a data journey Explore this chapter ↗ Interactive explanations Explore this chapter ↗ 20 technical questions Explore this chapter ↗ Connections & customer knowledge Explore this chapter ↗ Roles & responsibility Explore this chapter ↗ Consumer & SME transparency Explore this chapter ↗ The value of linked data Explore this chapter ↗ Reading names & records Explore this chapter ↗ Granular research guide Explore this chapter ↗ Public sources & research notes Explore this chapter ↗ Privacy notice Explore this chapter ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#publication-scope", "heading": "A public learning resource, informed by experience.", "text": "A public learning resource, informed by experience. This edition contains general explanations, invented teaching examples and public reference material. Case-specific evidence, correspondence and procedural records are maintained separately and are not published here. Supporting case material may be provided separately to appropriate reviewers where necessary and appropriate. We will add further research and worked examples over time, with their sources, assumptions and revision dates. Each explanation should be read with its assumptions and sources. Sources & research notes →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#research-articles-entry", "heading": "Explore the blogs.", "text": "Explore the blogs. Follow focused explanations of corporate cinema ticket journeys, service layers and the questions consumers and SMEs can ask. Browse the blogs →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/index.html#corporate-records-entry", "heading": "Follow the company through change.", "text": "Follow the company through change. A new corporate story can leave an earlier transaction question behind. Explore the dated-record example and the records that connect the two. Corporate changes & records →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/directory.html", "title": "Research directory", "sections": [ { "id": "https://filmpass.nsstudio.uk/directory.html#section-1", "heading": "The research directory.", "text": "BROWSE THE WHITE PAPER The research directory. Our journey, closed user groups, technical examples, diagrams and public-source research—in one place. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/directory.html#guide", "heading": "Choose a chapter.", "text": "Choose a chapter. A growing educational reference, informed by our experience buying corporate cinema tickets. Use the chapters independently or follow the reading order.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#directory-0", "heading": "Begin with the journey", "text": "Begin with the journey Our journey & purpose Open this chapter ↗ Closed user groups & benefits Open this chapter ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#directory-1", "heading": "Understand the mechanisms", "text": "Understand the mechanisms Follow a data journey Open this chapter ↗ Interactive explanations Open this chapter ↗ 20 technical questions Open this chapter ↗ Connections & customer knowledge Open this chapter ↗ Roles & responsibility Open this chapter ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#directory-2", "heading": "Read the research", "text": "Read the research Consumer & SME transparency Open this chapter ↗ The value of linked data Open this chapter ↗ Reading names & records Open this chapter ↗ Public records & research examples Open this chapter ↗ Granular research guide Open this chapter ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#directory-3", "heading": "Sources and publication", "text": "Sources and publication Public sources & research notes Open this chapter ↗ Privacy notice Open this chapter ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#research-articles-entry", "heading": "Explore the blogs.", "text": "Explore the blogs. Follow focused explanations of corporate cinema ticket journeys, service layers and the questions consumers and SMEs can ask. Browse the blogs →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/directory.html#corporate-records-entry", "heading": "Follow the company through change.", "text": "Follow the company through change. A new corporate story can leave an earlier transaction question behind. Explore the dated-record example and the records that connect the two. Corporate changes & records →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html", "title": "Closed user groups & benefits", "sections": [ { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#section-1", "heading": "Closed groups. Access, information and control.", "text": "CORPORATE CINEMA · MEMBER BENEFITS Closed groups. Access, information and control. Who controls the doorway to a benefit, who operates the services behind it, and what happens to the information generated along the way? The discount is visible. The information journey should be visible too. Begin with access, follow the records and ask what changes when they reach another system. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#who-this-is-for", "heading": "The people behind the benefit.", "text": "The people behind the benefit. Our educational focus includes corporate employees, customers in loyalty programmes, key workers, police and armed-forces communities. An employer, membership body or benefits provider may arrange access, while other organisations supply tickets, take payment or handle redemption. These are different roles. A person’s eligibility for an offer does not, by itself, explain which organisations receive their details or how later records are used. Our starting concern is the member’s understanding: the benefit offered is a discount, a reward or a cinema ticket. Employees, key workers, police and armed-forces communities should be able to understand whether using that benefit also builds a profile, which organisations can use it, and how to challenge an unexpected use.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#behind-the-benefit", "heading": "Who is behind the closed group?", "text": "Who is behind the closed group? An employer-branded rewards message can lead to a programme managed by another company, offers supplied by retailers and a separate account or points service. Read the invitation, operating terms, checkout and privacy information together. Each can identify a different part of the arrangement. Role to identify Information to trace Question for that organisation Employer or membership sponsor Eligibility, enrolment and any reporting back What do you supply to the operator, and do you receive identifiable purchase or browsing information? Programme operator Member account, preferences, clicks and reward balance Which company runs the programme and decides how those records are used? Retailer or ticket supplier Order, invoice, ticket and redemption records Who sells the product, fulfils it and handles a refund or complaint? Commerce platform and payment services Platform accounts, connected sellers, payment events and accessible results Which platform receives events from which accounts, and which fields reach it? Marketing, reporting and customer systems Campaign references, joined records, segments and inferred interests Which recipients use these records, for what purpose, for how long and in which countries? A statement about who endorses a retailer answers a different question from who controls the programme’s information. Ask for both explanations. The ICO’s transparency guidance covers purposes, recipients, retention and relevant international transfers. Read the transparency requirements ↗", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#four-stages", "heading": "Four stages worth separating.", "text": "Four stages worth separating. Stage Example record Question to ask Eligibility Membership status or an eligibility result Does the supplier receive only confirmation of access, or the person’s employer or group? Purchase Order, payment and supplier identifiers Which company sells the stock, and which records are about the SME buyer? Redemption Ticket code, venue and booking event Can the redemption be connected to the member or the earlier stock order? Later use Reports, segments or risk outputs, if created Which fields are retained, who can access them and what decisions use them? Use this checklist to identify the records created at each stage. Joining them requires accessible fields and a matching method.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#access-and-choice", "heading": "Can you use the benefit without marketing profiling?", "text": "Can you use the benefit without marketing profiling? If declining profiling blocks access, ask exactly which processing is required, why it is necessary and which lawful basis the operator relies on. Eligibility Confirming access may need an eligibility result. Ask whether the next service also receives the employer, occupation, membership category or verification document. Delivering the service Account security, ticket delivery, payment and reward allocation each generate records. Ask which fields are needed for each function and how long they remain available. Marketing and enrichment Inferring interests, combining purchases or assigning advertising audiences is a further purpose. Ask where that purpose is explained and which choice or objection controls it. Where consent is relied on, it must be specific, informed and freely given. Making service access depend on consent to processing that is unnecessary for that service raises a direct question about whether that choice is genuine. A benefit tied to joining a marketing scheme also needs examination of the actual offer and any pressure to agree. Acknowledging a privacy notice is not itself consent to every use described inside it. ICO: valid consent · Planning direct marketing If an organisation relies on legitimate interests, ask for its purpose, necessity and balancing explanation for that particular marketing activity. Electronic marketing and tracking also have PECR requirements. Individuals have an absolute right to object to direct marketing, including profiling related to it. Ask whether an unsubscribe setting stops only messages, or also the associated profiling and use of audiences downstream. ICO: the right to object", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/consent/what-is-valid-consent/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/plan-direct-marketing/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-object/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#two-suppliers", "heading": "Follow the platform as well as the suppliers.", "text": "Follow the platform as well as the suppliers. In the teaching example, an SME buys cinema stock from Supplier A and Supplier B, then supplies members. The systems to examine include each supplier’s storefront and any platform receiving events from their payment accounts. To test a proposed connection, identify the specific field, account permissions, transfer or query, destination and subsequent use. A shared email address, ticket identifier or device identifier matters only where the relevant party can actually access and use it. The SME’s stock purchase and the member’s later redemption are separate events. Avoid treating the payer, cardholder, employee, member and person operating a browser as automatically the same person. Follow the records step by step → Stripe Connect documents a mechanism for a platform’s configured webhook endpoint to receive events associated with connected accounts. The event scope and account configuration determine the route. Identify the platform operator, connected accounts, subscribed events, accessible fields and destination services. These records help explain what the platform can see across the suppliers it serves. Stripe Connect: account events and webhooks ↗", "sources": [ "https://docs.stripe.com/connect/webhooks" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#reported-access-case", "heading": "When the storefront stops, what access remains?", "text": "When the storefront stops, what access remains? Case study · public incident report and documented capabilities Removing a checkout and ending access to a payment account are separate actions. A reported incident makes the distinction worth examining. Separate research report: linked records and exposed keys In its report dated 25 August 2026 , iCOUNTER said it had confirmed 662 valid API keys in a release involving Stripe users’ customer, transaction and invoice records. Cybernews described customer references connecting people to transactions, products and businesses, alongside shop-level statistics. This combination can reveal purchasing patterns and make targeted phishing more convincing. The documented categories here are customer, transaction, invoice and account records. The reports do not establish that the dataset contains raw Radar behavioural telemetry. They also do not establish a connection with the Reddit incident below. iCOUNTER: research report, 25 August 2026 ↗ · Cybernews: reported data categories and linkage ↗ What the merchant reported In a public Reddit post, a merchant reported invoices being sent without their authorisation. They said the activity recurred after they expired API keys, removed Stripe from their webstore, changed platforms and retired the old server. They also described difficulty stopping further activity while pending transactions prevented account closure. A reply from the Stripe support account offered direct investigation. Read the original public thread ↗ Source status: a user-reported experience. The visible thread supplies no request logs, complete access inventory or confirmed technical cause. Reviewed 2 November 2026. What the technical documentation establishes Stripe describes secret API keys as account credentials. Its guidance explains that an unauthorised holder can access customer data or perform payment actions, and that restricted keys can limit the operations available. It also recommends examining API request logs. These are capabilities and controls to inspect in the affected account. Stripe: API key access and incident handling ↗ Separately, Stripe’s Connect OAuth reference documents platform access to Standard accounts and a revocation mechanism that ends that platform’s Dashboard and API access. A commenter raises Connect as a possibility in the thread; the incident’s account configuration is not established there. Stripe: connected-platform access and revocation ↗ Trace the access, then the response Question Record needed to answer it Which route created each disputed invoice? Request and account activity records, timestamps, authentication context and invoice events Which credentials or connected applications still had access? The credential and application inventory, permissions, expiry and revocation records What could that access read or change? The actual permission scope and affected customer, invoice or payment records Who could suspend the activity, and what happened after notification? The incident escalation record, actions taken and evidence that further activity stopped Identifying an entry point does not answer the whole incident. The practical explanation needs to cover the remaining permissions, the actions they enabled and the response that stopped them. For a connected benefits platform, the question carries through: when a storefront, supplier integration or commercial relationship ends, can the operator account for every remaining route into the associated records? The same connection can support another use An API is a connection mechanism. A ticketing system can supply permitted order or redemption fields to a supplier integration; that integration can pass available fields to another service. If a receiving customer system can match those records to an account, it can use the combined history for segmentation. The route to examine is the ticket event, the fields returned, the receiving integration, the matching key and the later use. The label “ticket fulfilment” describes one function; tracing the destinations establishes the rest. Access misuse and purpose change are separate investigations. The first examines who could act without authorisation; the second examines what a recipient did with information it could access. Both require a view across permissions, records and destinations. Follow the connected-system diagram →", "sources": [ "https://icounter.com/blog/why-compromised-apis-are-a-supply-chain-threat", "https://cybernews.com/security/stripe-data-breach-cybercrime-forum/", "https://www.reddit.com/r/stripe/comments/1vlydm6/stripe_has_apparently_absolutely_no_security/", "https://docs.stripe.com/keys-best-practices", "https://docs.stripe.com/connect/oauth-reference#revoke-the-accounts-access" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#api-notice-dates", "heading": "A security notice. Four days. A reported exposure.", "text": "A security notice. Four days. A reported exposure. Dated sources · API permissions and connected accounts Stripe’s API-key notice displays 14 August 2026. Hudson Rock’s report dates a vendor-data release to 18 August. Put those dates beside the earlier guidance and ask what prompted the update. Keep the stated update, reported event and contract-effective dates distinct Date Source and what it records 2024 Stripe’s plugin migration guide describes support introduced on 1 January, a developer requirement from 30 September and a merchant upgrade programme beginning 29 October. The guide explains the risk of sharing broad secret keys with third-party services. Read the migration guide ↗ 18 November 2025 Stripe’s prior-version General Terms PDF bears this modification date. Section 3 already contains the security-loss allocation paragraph also found in the September 2026 version. Compare the prior terms, PDF pages 9–10 ↗ 14 August 2026 The API-key security notice’s displayed last-updated date. It describes customer-data access and effects extending from a platform to connected accounts; it also addresses responsibility for compromise losses. Read the notice ↗ 18 August 2026 Four days later Hudson Rock’s 19 August research report dates the release to this day. It reports 669 vendor folders and 1,033 keys, with a reported volume of 33 GB. Read the researchers’ account ↗ 28 September 2026 The UK Services Agreement’s displayed modification date. Section 3 addresses account security and loss allocation, including exceptions for Stripe’s gross negligence, fraud or wilful misconduct. Read the UK agreement ↗ 6 January 2027 Stripe’s update explanation gives this effective date for changes to General Terms for existing users. New users and new services have different effective-date provisions. Read the applicability and notification dates ↗ The notice labels 14 August as its last update; it does not supply a first-publication date or a version comparison. It describes itself as supplementing the applicable Stripe agreements. Read the actual wording and the version applicable to the account and transaction date. The security-loss paragraph is present in both the prior-version PDF and the September 2026 terms. The comparison therefore needs to identify the particular clauses or warnings that changed, alongside the date shown on each document. What did the customer-facing explanation actually say? The migration guide addresses merchants and plugin connections. To examine what a benefit member was told, retain the exact checkout and privacy notices shown at the time. Compare whether those notices identified the platform operator, the accessible data, the receiving integrations and any further use for profiles or marketing. An allocation of financial losses between contracting businesses answers a different question from the explanation given to the person whose information is involved. Questions raised by the dated record What prompted the 14 August notice update, what changed, and when did Stripe first become aware of the exposure reported on 18 August? What warnings, permissions and key-security requirements applied during transactions in 2023–24? Which notice and agreement versions were supplied to the platform and connected merchants? What did the customer-facing notice explain about platform access, data available to integrations and possible onward use? Which integrations still held broad secret keys after the migration programme, what access remained, and how was compliance checked? Which fields could each key or connected application read, which account records were accessed, and what request logs establish the destinations? What changed in the September agreement compared with the preceding version, when did each change apply, and how were connected accounts notified? From access to subsequent use A permission can expose customer, invoice or payment fields to another system. To examine later enrichment, identify those exact fields, the matching identifier, the receiving dataset and the query or rule that created the profile. Record which fraud-assessment outputs were available separately from internal telemetry. A description of the product’s purpose does not provide that field-by-field account. Follow the accessible records through the connected-system diagram →", "sources": [ "https://support.stripe.com/questions/plugin-user-migration-guide?locale=en-GB", "https://assets.stripeassets.com/fzn2n1nzq965/TJYsZOVIGObEhuOKwIN6u/365201c88376e26bb451727a4aff47f0/Stripe_Services_Agreement_-_General_Terms.pdf", "https://stripe.com/legal/api-key-security", "https://www.infostealers.com/article/analyzing-stripe-breach-confirmed-vendor-exposure-and-claims-of-20000-compromised-apis/", "https://stripe.com/gb/legal/ssa", "https://support.stripe.com/questions/stripe-user-terms-update-september-28-2026?locale=en-GB" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#one-complete-account", "heading": "Ask for one complete account.", "text": "Ask for one complete account. A dispute can span a storefront, a platform, a payment service and a receiving customer system. Put the separate responses beside the complete information journey. Identify what each answer covers and what remains unanswered. From a separate explanation to the records needed for a complete answer Type of response What it addresses Question still to answer Records to identify The merchant secures the API key Responsibility for handling a credential Which integrations held access, what could they read or change, and what did they actually do? Credential inventory, permissions, access logs and revocation history The transaction has finished The completion of a payment or redemption Which records and derived outputs persist, who can still retrieve them, and what stops subsequent use beyond the authorised purpose? Retention schedules, stored fields, access policies, export history and downstream deletion records We are not the data controller A stated role for a processing activity If the organisation uses records or derived profiles for its own commercial purposes, who decides that use and how does its stated role reflect those decisions? Purpose-by-purpose role assessment, processing instructions, lawful basis, notices and decisions about matching or enrichment The product is for fraud prevention The stated purpose of a product Which outputs reached other systems, and what purpose did each receiving system use them for? Field definitions, reports, exports, connector settings and destination queries We do not share that data A statement whose scope needs to be defined Which data and recipients does the answer cover? Does it address derived scores, linked records, platform access and onward outputs? A field-by-field response, recipient list, access routes and transformation rules The agreement allocates the losses Contractual allocation of financial responsibility What happened, which agreement version applies, and what explanation did the affected customer receive? The applicable contract, effective-date notice, incident record and customer-facing disclosures Another company handles that part One organisation’s stated role Which company took responsibility at the handover, and who will coordinate the complete response? Company numbers, role allocation, handover records and complaint ownership The current record has been updated The position displayed now What did the earlier version say, what changed and which underlying record supports the change? Original and replacement documents, event dates, filing dates and the explanation for amendment The payment ends. What happens to the information? Stored transaction records, linked identifiers and derived attributes can remain useful after payment or redemption. Follow three distinct stages: what remains stored, what can still be accessed, and what has already been copied elsewhere. Each stage needs an identified purpose, a retention period and controls that can be tested. 1 · Records retained Which customer, purchase, invoice and risk-result fields remain? Why is each needed, for how long, and can it still be linked to a person or business? 2 · Access still available Which keys, platform accounts and connectors can read historical records? What prevents excessive retrieval or reuse, which controls were enabled at the time, and what do the access logs show? 3 · Copies and derived profiles Revoking access blocks future requests through that credential; it does not itself erase copies already received. Who tracks those copies, transformations, further recipients and deletion? Ask the infrastructure provider: Which controls prevent or detect access beyond the approved scope, and what controls govern information after an authorised export? Where does responsibility pass to another organisation, and what evidence shows that the restrictions continue there? Stripe documents restricted keys and access policies. Its privacy material also describes retention beyond the last transaction. Use the version and configuration relevant to the period being examined, then ask for the actual fields, permissions and logs. API permissions and access policies ↗ · Privacy roles and retention ↗ Commercial use: who makes the decisions? If an organisation decides to combine records, build a profile or select an audience for its own commercial purpose, ask it to identify its controller responsibilities for that activity. The ICO assesses who determines the purpose and means; a contractual label does not settle that question. Its checklist treats commercial benefit as one indicator, while distinguishing it from payment for processing services. “If you use these records or derived profiles for your own commercial purposes, who decides that use, and how does your stated controller role reflect it?” Request the named legal entity, the purpose, the source fields, the matching or transformation steps, the recipients, the lawful basis and the explanation given to the person. Track responsibility separately for payment execution, fraud assessment, retention and any later enrichment. ICO: deciding controller and processor roles ↗ · Explore the value of linked data → The question across the whole chain Who can provide a complete account of what data moved, who accessed or used it, for which purpose, and what happened after the concern was raised? Ask each organisation to identify the part it can answer, the records supporting its answer and the organisation responsible for any remaining part. Keep those answers together so a referral between companies does not lose the original question. For each response, record the question asked, the answer received, its date, the documents relied on and the point still outstanding. Preserve the earlier wording when a policy, contract or register entry changes. Trace the information route → · Compare company identities and original filings → · Use the technical question checklist →", "sources": [ "https://docs.stripe.com/keys", "https://stripe.com/legal/privacy-center", "https://cy.ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors-a-guide/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#commercial-value", "heading": "Targeting creates questions about the member’s information.", "text": "Targeting creates questions about the member’s information. Planit’s article on closed user groups describes their appeal to affiliate marketers: defined audiences, eligibility checks, targeted campaigns and repeat purchasing. It gives examples of employee, student and professional groups. This is a commercial publisher’s account of the channel. Our question follows from that description: what does a participant understand about the information used to make an offer relevant? Planit · Importance of Closed User Groups · Published 26 June 2025; updated 23 July 2025. Reviewed for this example on 31 October 2026. What makes the audience valuable: verified eligibility, purchase history, inferred interests, or a combination? Which of these can the operator pass to a retailer, agency or customer system? Can a member see the profile or segment applied to them, and how is it changed after an objection? Explore the value of linked information →", "sources": [ "https://www.planit.co.uk/post/importance-of-closed-user-groups" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#purpose", "heading": "Fraud prevention and later use need their own explanation.", "text": "Fraud prevention and later use need their own explanation. Security checks, eligibility checks, order fulfilment and marketing are different purposes. Follow the actual fields: a merchant’s order data, accessible payment or assessment results, and a provider’s internal security telemetry. A report or connector exposes the fields available to that account; the destination can then join, transform or use those fields under its own rules. The ICO’s fraud-sharing guidance asks organisations to establish responsibilities and lawful bases, limit use to justified purposes and respect information rights. The guidance is marked as under review following the Data (Use and Access) Act. Check the applicable rules and documentation for the relevant date. ICO · Sharing personal information to prevent scams and fraud · Reviewed 31 October 2026. Use the 20 technical questions → A statement that a product prevents fraud describes its security function. To examine later use, ask what outputs reach another system and what that system does with them. Using an accessible result or an overlapping merchant record can create a different route from exporting the provider’s internal raw signals.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#where-context-can-be-lost", "heading": "Where the information can acquire another purpose.", "text": "Where the information can acquire another purpose. Consider this worked route through connected services. At each step, identify the input, the permission to receive it and the rule that changes its meaning. Follow the route · example records 01 Access 02 Offer click 03 Purchase 04 Redemption 05 Further use A member enters through a familiar benefit. Eligibility result · member reference · sponsor or group, if supplied The visible action is proving eligibility. Examine whether the operator keeps only an access result or also information about employment, occupation or group membership. Ask: which information passes to the next service, and what does that recipient use it for? A personalised link can connect the next event. Recipient or campaign reference · destination · recorded click time A link can carry an identifier through a redirect. If a receiving system has the corresponding mapping, it can associate an event with an account or campaign. Inspect the actual parameter, destination and mapping. Ask: does the link measure engagement, authenticate access, allocate a reward, or perform more than one function? An order creates more records. Order reference · product · payment status · accessible assessment result, if supplied Checkout, invoice and payment services each hold parts of the transaction. A configured platform can receive permitted account events; a connector can pass available fields into reporting. Ask: which fields reach the platform, warehouse or customer system, and where are those destinations recorded? Redemption can extend the history. Ticket reference · claim or redemption event · account or order match, where available Claiming or using a ticket may create another event. Linking it to the original purchase needs a common identifier or an accessible mapping between the records. Ask: who receives confirmation, whether it identifies the member, and whether the purpose extends beyond fulfilment or reward allocation? A joined record can become a customer label. Joined history · inferred interest or frequency · audience or decision rule A receiving system can calculate a new label from the fields it has. Reusing an accessible security-related result for an unrelated commercial segment changes the purpose to examine. The original raw security inputs need not all be present in that receiving system. Ask: which source fields and rules produced the label, what action uses it, and how an objection reaches each destination? Email pixels, decorated links and device identifiers can support measurement and matching. The ICO explains their operation and the rules for storage or access on devices. Consent to receive an email and the requirements for its tracking technologies are separate checks. ICO: tracking technologies and link decoration · Tracking within email Gap to examine What to request An eligibility result becomes a marketing attribute The fields passed onward and the purpose recorded for that use A security or transaction result becomes a customer label The source field, transformation rule, new label and action it triggers Separate suppliers feed a common customer record Matching keys, tenant permissions, queries and recipient access records An opt-out stops email but a related marketing segment persists The preference scope, suppression rules and downstream updates Records move to another service or region Receiving entities, hosting and access locations, transfer arrangements and retention The ICO’s marketing guidance requires organisations to explain profiling, including enrichment from third parties or public sources. Ask for the explanation of the complete route, alongside each service’s description of its own role. ICO: profiling and enrichment ↗ Explore the connected-system diagram → Turn the route into technical questions →", "sources": [ "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-storage-and-access-technologies/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/what-else-do-we-need-to-consider/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/collect-information-and-generate-leads/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#read-the-language", "heading": "Turn reassuring phrases into answerable questions.", "text": "Turn reassuring phrases into answerable questions. Phrase a member may encounter Question it leaves open Record that helps answer it “Fraud prevention to protect members” Which fields are collected, which outputs are accessible elsewhere, and are any of them used for another purpose? Collection inventory, output schema, destination and purpose assessment “Trusted partners” Which recipients or categories, which roles, which countries and which uses? Recipient information, processing purposes and transfer arrangements “Anonymous insights” What identifiers or matching information remain, and who can reconnect the record to a person? Identifiability assessment, matching keys and access controls “We do not store card details” Which payment references, statuses, account identifiers or other transaction records are retained? The actual stored fields and retention schedule “Personalised experience” Which inputs produce the profile, what decisions use it, and can the person inspect or challenge it? Profile fields, source records, segment rules and rights process “Unsubscribe” Which messages, marketing profiles and downstream uses stop? Preference scope, suppression records and recipient updates Replacing a name with a reference does not settle whether the information is anonymous. Where additional information can reconnect the reference to a person, examine who holds that information and how identification could occur. The ICO distinguishes pseudonymisation from effective anonymisation and describes the risk of linking records across datasets. Pseudonymisation · Linkability and identifiability", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/how-do-we-ensure-anonymisation-is-effective/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#why-transparency-matters", "heading": "Why work-linked information needs particular care.", "text": "Why work-linked information needs particular care. When a person’s work or service affiliation can be connected to identifiable activity, the consequences of exposure can extend to their workplace, family and personal safety. NPSA’s guidance for people at higher risk explains how digital footprints and information about activities or routines can assist hostile targeting. The concern to examine in a benefits system is the combination: who the person is, which group they belong to, and what additional activity or location information an accessible record reveals. Recognisable affiliation Employment or service eligibility, when linked to a person, can help identify people in roles of interest to an attacker. Convincing approaches If an attacker obtains genuine purchase, reward or account details, those details can make a fraudulent support message or targeted approach more credible. Accumulated exposure Linked activity or location records can reveal more than an isolated event. Examine the granularity, retention and access to the combined history. These risks make the timing of transparency important: members and sponsors need to understand collection and further use before information spreads across services. Ask for data minimisation, restricted access, retention limits and a practical way to exercise choices across the connected route. NPSA: digital footprints and online targeting · Protecting information about you · Recognising targeted approaches", "sources": [ "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/be-vigilant-online", "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/protect-information-about-you", "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/are-you-being-targeted-or-someone-trying-access-your-information-or-accounts" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#voucher-classification", "heading": "SPV or MPV: follow the ticket and the accounting.", "text": "SPV or MPV: follow the ticket and the accounting. Here, SPV means single-purpose voucher and MPV means multi-purpose voucher . Start with the instrument’s terms: admission tickets, discount codes, points and exchangeable vouchers can have different treatment. Under the rules for vouchers issued from 1 January 2019, an SPV has a known place of supply and VAT liability when issued. An MPV is a voucher that does not meet that definition. This affects when VAT is accounted for across issue, transfer and redemption. A closed membership group or the number of brands displayed does not determine the classification. Ask who issues the voucher, who sells it to the SME, who must accept it, what it can buy and which invoice records each stage. HMRC distinguishes vouchers from admission tickets and discount vouchers, so check the product actually supplied. HMRC VAT Notice 700/7, section 9 ↗ The information journey needs its own explanation: which account claims the code, which records redemption creates and which later systems receive those records. Trace those questions alongside the accounting route.", "sources": [ "https://www.gov.uk/guidance/business-promotions-and-vat-notice-7007" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#who-answers", "heading": "Who must answer—and where can concerns go?", "text": "Who must answer—and where can concerns go? Ask the sponsor for the programme operator’s legal identity, the operator for the account and information route, and each supplier for its part of the purchase or redemption. Request a response to each organisation’s own processing, including the fields, purposes and recipients involved. Concern Relevant route Useful record to preserve Personal information, profiling, consent or information rights Raise it with the organisation; the ICO handles data-protection concerns The notice, choices offered, request and response Advertised saving or promotion terms ASA advertising and promotion complaints The dated offer, comparison price and significant conditions Potential competition or consumer-law concerns CMA reporting guidance ; the appropriate consumer advice route for an individual dispute The conduct, parties, affected market and supporting records Voucher classification and VAT treatment HMRC guidance and the supplier’s accounting explanation Voucher terms, invoice, issuer and redemption conditions Keep the question specific: “Which information about me or my business enters this system, who can connect it to other records, what is done with it, and how can I exercise my choices?” Guidance checked 2 November 2026. For earlier events, use the terms, configuration and rules applicable at that time.", "sources": [ "https://ico.org.uk/for-the-public/how-to-make-a-data-protection-complaint/", "https://www.asa.org.uk/make-a-complaint.html", "https://www.gov.uk/guidance/how-best-to-make-a-competition-or-consumer-law-complaint-and-what-happens-next" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/closed-user-groups.html#critical-purpose", "heading": "Membership is not a privacy assurance.", "text": "Membership is not a privacy assurance. This research examines commercial incentives, transparency and potential harms in closed user groups. Descriptions such as “closed”, “trusted” or “exclusive” do not establish that a scheme is ethical, that its data use is compliant, or that members understand the wider commercial relationships. The questions are practical: who benefits from the information generated around a ticket, who can connect it to other records, for which purpose, and what can the member see or challenge? Verification of eligibility does not answer those questions.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/public-research.html", "title": "Public records & research examples", "sections": [ { "id": "https://filmpass.nsstudio.uk/public-research.html#section-1", "heading": "Public records. Questions you can check.", "text": "PUBLIC RESEARCH · SOURCE DIRECTORY Public records. Questions you can check. Keep the published records in view, and distinguish what they show from what still needs establishing. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#reading-sources", "heading": "Public sources remain part of the research.", "text": "Public sources remain part of the research. Company registers, published policies, product documentation and articles can help explain a system. Each source answers a different question: a register records filed company information; product documentation describes available functionality; an article presents its publisher’s explanation. These sources are not private correspondence or disclosures. We link to the originals, avoid reproducing personal names, and distinguish the source’s contents from our interpretation. External websites remain under their publishers’ control and may contain names or other information not reproduced here.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#public-examples", "heading": "Two ways to test a public explanation.", "text": "Two ways to test a public explanation. Company identity Compare two displayed names with the same company number, then check the name history. Read the Companies House example → Cinema savings claims On 14 December 2022, the ASA upheld a complaint about Taste Marketing Ltd’s “Up to 40% off” cinema-ticket claim. The published ruling includes the advertiser’s response and the ASA’s assessment. The educational question is how a saving is calculated: compared with which ticket, venue, time and usual price? This ruling concerns that advertisement. Read the ASA ruling and response → Reviewed 31 October 2026.", "sources": [ "https://www.asa.org.uk/rulings/taste-marketing-ltd-a22-1155526-taste-marketing-ltd.html" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#corporate-change-dates", "heading": "Following a company through changes.", "text": "Following a company through changes. A current company name, a change of control and the date a document was filed can describe different parts of the same history. Compare the legal entity, event date and record date before connecting events. Event or reference date What the public source records Record date and source 31 December 2024 Mission's results identify the disposal of April Six. This is a subsidiary disposal, rather than a sale of Mission itself. 24 March 2026: Mission's later results restate this disposal date. Company RNS announcement held by the FCA . 31 December 2025 Ello Group Holdings Ltd (09685437) has significant-control entries and share-capital events effective on this date. Control notifications filed on 27 January 2026; share consolidation filed on 9 February 2026. Companies House filing history . 1 May 2026 — article update date The purchaser's legal adviser describes acting for Dragonpass Group on its acquisition of Ello Group Holdings Ltd. The article describes completion over the festive period; its displayed update date is not the completion date. Acquisition adviser's published account . What this comparison establishes: identifiable public events and the different dates attached to them. Ask: What changed—name, ownership, assets or control? Which legal company was involved? When did the event take effect, and when was it recorded publicly? An accounts year-end is not automatically a transaction date. Read this alongside the same-company-number and name-history examples . A current name displayed beside a historical date should be checked against the name in force at that time; the display alone does not establish deliberate backdating. Public sources checked 1 November 2026. Source links lead to third-party publications; personal names in those sources are not reproduced here. Compare three 2022 name changes and the original 2021 accounts covers → Compare Ello’s original and replacement share-class notices →", "sources": [ "https://data.fca.org.uk/artefacts/NSM/RNS/61890f2f-0595-4656-9319-8433aeb41f9a.html", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history", "https://www.shma.co.uk/our-thoughts/shakespeare-martineau-advises-dragonpass-major-uk-acquisition/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#company-directory", "heading": "Company-record directory.", "text": "Company-record directory. Public register links retained from our earlier research. This is a reading directory, not a chronology of alleged wrongdoing. Individual filing documents need to be read in full before drawing conclusions; inclusion does not independently verify the accuracy of the filing. 05545626 · Control register 09578541 · Company overview and name history 09975027 · Filing document 09578541 · Filing document 09975027 · Filing document 09578541 · Filing document 09578541 · Filing document 03940640 · Filing document 03940640 · Filing document 03940640 · Filing document 05545626 · Filing document 05545626 · Filing document 09685583 · Filing document 09685583 · Filing document 09975027 · Company overview and name history 09685437 · Company overview and name history 09685583 · Control register 09685583 · Filing history 03988503 · Filing history 05119718 · Filing history 05119718 · Control register", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/05545626/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09578541", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzMyOTc3Nzk4N2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzOTM5MTcxOGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzM1MTM2ODkzOGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzOTM5MjE5OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzMDI5NTIzNmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MDM2OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MDc1NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MjY3NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/05545626/filing-history/MzMzMjE5MzM2NGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/05545626/filing-history/MzMzMjE5MzM2OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzg0NWFkaXF6a2N4/document?download=0&format=pdf", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNTk1MGFkaXF6a2N4/document?download=0&format=pdf", "https://find-and-update.company-information.service.gov.uk/company/09975027", "https://find-and-update.company-information.service.gov.uk/company/09685437", "https://find-and-update.company-information.service.gov.uk/company/09685583/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history", "https://find-and-update.company-information.service.gov.uk/company/03988503/filing-history", "https://find-and-update.company-information.service.gov.uk/company/05119718/filing-history", "https://find-and-update.company-information.service.gov.uk/company/05119718/persons-with-significant-control" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#adding-research", "heading": "A living white paper, with a clear record of revisions.", "text": "A living white paper, with a clear record of revisions. Future additions will identify the question, the source and its date, the mechanism or observation, the conditions required and the limits of the conclusion. We will record substantive changes rather than silently presenting later research as an earlier publication. Private emails, letters, disclosures, transaction schedules and court or complaint documents are maintained separately. They are not embedded here or released through a PIN.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/public-research.html#corporate-records-example", "heading": "From register entries to a complete sequence.", "text": "From register entries to a complete sequence. See how names, disposals, financial presentation, reporting dates and adviser changes fit together in a fictional chronology. Open the interactive corporate-record example →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html", "title": "Follow a data journey", "sections": [ { "id": "https://filmpass.nsstudio.uk/data-journey.html#section-1", "heading": "A ticket. A decision. A possible data journey.", "text": "05 / HOW PAYMENT DATA WORKS A ticket. A decision. A possible data journey. An unnamed, fictional example. Learn what is generated, what a business may be able to query, and which extra steps are needed for a CRM record. Illustrative mechanism ↗ One checkout. Different records. One checkout. Different records. CHECKOUT → ORDER RECORD → DEVICE SIGNALS → TRACE THE LINKS. Collection, access and later use are separate questions. CHECKOUT ORDER RECORD DEVICE SIGNALS TRACE THE LINKS Collection, access and later use are separate questions. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "One checkout. Different records. CHECKOUT → ORDER RECORD → DEVICE SIGNALS → TRACE THE LINKS. Collection, access and later use are separate questions. CHECKOUT ORDER RECORD DEVICE SIGNALS TRACE THE LINKS" ] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#diagram-purpose", "heading": "Follow a data journey", "text": "How to read this explanation. The technical explanation describes how records can be linked and reused when the stated access, identifiers and integrations are present. The names, amounts and sample records are invented to demonstrate the mechanism. The examples do not reproduce private case records. Provider-specific field availability and each assumed step are identified separately.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#section-3", "heading": "A customer buys a ticket.", "text": "Start with A new ticket purchase An existing ticket redemption Redemption includes a new payment Play journey Reset ← Previous Step 1 of 6 Next → ILLUSTRATIVE EVENT A customer buys a ticket. A checkout can create an order and payment record. The demonstration uses invented identifiers and a £20 purchase. ILLUSTRATIVE RECORD · NOT REAL CUSTOMER DATA {\"order\":\"order_demo_01\",\"value\":\"GBP 20.00\"} The scenario identifies ticket events, payments and fraud checks as separate steps. Official technical source ↗ A route with purpose checks This first animation requires the purpose check before presenting an authorised-use scenario. Software could still move data without that authority; the matching example below separates technical possibility from justified use. Selected fields exported A usable matching identifier exists Destination purpose and authority established Purpose and authority remain unresolved in the initial scenario.", "sources": [ "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#section-4", "heading": "Fraud prevention", "text": "Fraud prevention Signals help assess whether a payment could be unauthorised or fraudulent. A risk score represents the system’s assessment of a transaction. Reporting, including Sigma An authorised business can query data available to its account. Only exposed fields can be selected; the available fields and account scope define the query. A separate CRM integration An export or integration can map selected fields into a receiving system. A reliable identifier enables matching. Suitable permissions and a justified purpose must be assessed separately. A redemption can be a ticket-system event with no new payment. Neither a redemption nor a purchase automatically proves that fraud data reached a CRM. The example demonstrates a possible configured route. What do the terms mean? SME A small or medium-sized enterprise. CRM Customer relationship management: a system for customer records and interactions. Sigma Stripe’s reporting product for querying available account data. It is not itself proof that information was sent to a CRM. Matching identifier A value, such as a customer ID, used to associate a record with the correct customer. Matching can fail or join the wrong person, so it must be checked. Raw signals and derived results A device observation is an input; a payment-risk assessment is a result derived from inputs. Access to a result does not establish access to every input. Why transparency matters for SMEs and closed user groups → Tracing a transfer through its records Which field was available to which account, at the relevant date? Which query or export selected it, and where is the export log? Which integration transmitted it, to which destination? How was it matched, and what did the receiving CRM actually store? What purpose, authority, notice and retention rule applied? Technical sources Official sources checked 6 October 2026. Current documentation may differ from historic versions. Sigma overview ↗ SQL reporting and CSV export. Fraud analysis and reporting fields ↗ Merchant-visible risk results and schema mapping; check current account availability. Scheduled query results ↗ Configured exports and authenticated retrieval. Transactional data and customer joins ↗ Identifier-based joins within available account data. Advanced fraud detection ↗ Provider-stated treatment of device and activity risk factors, distinct from merchant-visible results. Example reporting query Illustrative query for account reporting. The fields available depend on the authorised account and schema. This example selects exposed payment fields. SELECT id, customer_id, outcome_risk_level\nFROM charges\nORDER BY created DESC\nLIMIT 10; The interactive demonstration requires JavaScript. Its sequence is: event → integrated fraud checks → available payment result → authorised reporting query → selected export → separately configured CRM integration. The sequence shown starts with a payment. Redemption events, exports, identity matching and destination purpose have their own records to examine.", "sources": [ "https://docs.stripe.com/data/sigma", "https://stripe.com/guides/improve-fraud-management-with-radar-and-stripe-data", "https://docs.stripe.com/data/schedule-queries", "https://docs.stripe.com/data/query-transactions", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#linked-records", "heading": "How context can follow a record.", "text": "ONE CUSTOMER JOURNEY / SEVERAL LINKED RECORDS How context can follow a record. The important question is which identifiers survive each step. A payment, its merchant metadata and a security assessment can concern the same transaction while remaining different records with different access rules. 1. Collection A checkout may send payment details and trigger separate device or activity requests. Stripe documents periodic requests to m.stripe.com. Trace each request and its fields separately. 2. Merchant context A merchant can attach custom metadata, such as an internal order reference, to supported objects. A tag can add context; it is not necessarily a unique person identifier. Metadata does not automatically copy to every related object. 3. Selected reporting Sigma can query available account data and join customer and charge records. A selected export may retain a usable reference. The query uses exposed account fields; internal device and activity telemetry has its own collection and disclosure records. Linking records does not require one network request. A single event can generate separate records that retain a common reference or a distinctive combination of attributes. In the teaching example, the linking information is deliberately retained so readers can see how a later system could reconnect the records. Collection and transfer records identify the fields available at each stage. Collection and transfer records identify the fields available at each stage. A device identifier is not a company registration number or automatically a payment-account identifier. Establish the scope and meaning of each field before comparing it. Stripe: advanced fraud detection ↗ · Stripe: metadata and copying rules ↗ · Stripe: transaction and customer joins ↗", "sources": [ "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://docs.stripe.com/metadata", "https://docs.stripe.com/data/query-transactions" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#identity-lab", "heading": "When can an exported record be linked to a person?", "text": "INTERACTIVE EXAMPLE / INVENTED RECORDS When can an exported record be linked to a person? Try the matching conditions using merchant report fields and an invented contact lookup. The records in this control are invented. Field in the export Unique customer key: cust_demo_014 Shared campaign tag: weekend_offer No matching field Receiver has the corresponding contact lookup Identifier belongs to the same account namespace Destination purpose and authority have been established Selected export cust_demo_014 Invented payment reference and the selected matching field. Receiving lookup A corresponding contact key A lookup and account scope are assumptions that must be demonstrated. Matching result A match is technically possible The matching conditions are present. Destination purpose and responsibility are separate fields to review. Purpose and authority remain unresolved. Matching capability and lawful authority are different questions. The demonstration can show a technically possible match even when the authority switch is off. A real match can be wrong; source identity, collisions and accuracy still need checking. A pseudonymous or hashed identifier may remain linkable when another party has the necessary matching information. Merely removing a name does not guarantee anonymity. A common campaign tag alone usually identifies a group, not a unique person. Combinations of fields can create further identifiability risks, which this simplified example does not model. ICO: pseudonymisation ↗ · ICO: indirect identification ↗ Follow the invoice and accounting trail →", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/can-we-identify-an-individual-indirectly/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-journey.html#timestamp-evidence", "heading": "How a record can remain linkable after a name is removed.", "text": "TIMESTAMPS, PAYLOADS & RE-IDENTIFICATION How a record can remain linkable after a name is removed. This educational example demonstrates a possible matching mechanism using retained timestamps and identifiers. Removing a name or replacing a card number does not automatically remove every way to recognise a person. Retained identifiers, order references or sufficiently distinctive attributes may permit a link if the recipient has the corresponding information. A precise timestamp retained in two copies of an event can contribute to matching them. Combined with an order reference, amount or other distinguishing attributes and an available identity record, it may allow a person to be recognised after a name is removed. Time alone is not always unique; clock differences, retries and concurrent events must be handled. ICO: pseudonymisation and additional information ↗ Read the structure before drawing a link. Check whether timestamps, identifiers and activity values belong to the same event. Separate arrays or columns are not automatically aligned. Record time zones, repeated events, missing values and the meaning of each identifier. A device identifier, merchant account identifier and company registration number answer different questions. Establish their scope before using them to join records. How an audit could trace a real transfer A complete request capture could show fields sent together, destination and time. An export schema, executed query, matching recipient record and access log could then show which fields moved and how they were linked. A timestamp match alone does not supply that end-to-end evidence. Stripe’s documentation describes periodic fraud-signal requests and states that advanced signals are used for fraud/security rather than advertising. Sigma’s documentation describes transactional reporting and CSV export of exposed account fields. Check the product configuration and documentation applicable to the event being examined. Advanced fraud documentation ↗ · Sigma documentation ↗ Fictional teaching example See what survives the removal of a name. Information available in the example Same millisecond only Same ID, with the mapping checked Matching ID plus sender and recipient logs Checkout record\n10:00:00.123\norder_demo_17 Other record\n10:00:00.123\nidentity unknown The timestamp is a candidate link. This control uses invented records to explore a transfer’s fields, purpose, authority, recipients and retention.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://docs.stripe.com/data/sigma" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/examples.html", "title": "Interactive explanations", "sections": [ { "id": "https://filmpass.nsstudio.uk/examples.html#section-1", "heading": "Fraud protection. The profile behind a payment.", "text": "THROUGH THE EYES OF AN SME & CONSUMER / THE DATA EXPLAINER Fraud protection. The profile behind a payment. A payment is an event. A profile can outlast it. When information collected to protect a transaction is reused, stripped of context or attached to the wrong conclusion, the person or business behind it may carry the consequences without seeing the record that shaped the decision. Education informed by experience Interactive explanations Primary-source research Illustrative mechanism ↗ The context changes the picture. The context changes the picture. ONE EVENT → CONTEXT RETAINED → CONTEXT LOST → EXAMINE THE EFFECT. Compare the routes, then ask for the actual records. ONE EVENT CONTEXT RETAINED CONTEXT LOST EXAMINE THE EFFECT Compare the routes, then ask for the actual records. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "The context changes the picture. ONE EVENT → CONTEXT RETAINED → CONTEXT LOST → EXAMINE THE EFFECT. Compare the routes, then ask for the actual records. ONE EVENT CONTEXT RETAINED CONTEXT LOST EXAMINE THE EFFECT" ] }, { "id": "https://filmpass.nsstudio.uk/examples.html#follow-purpose", "heading": "Same starting point. Different choices.", "text": "The concern is what happens to the information after collection. Fraud prevention protects legitimate customers and businesses. A different question arises when an actor obtains data for another purpose, changes its meaning or obscures its origin. The two-card tool illustrates a possible misuse mechanism and the access it would require. EXAMPLE 01 / FOLLOW THE PURPOSE Same starting point. Different choices. Play both routes Explore the stages 1 / 5 A / ACCOUNTABLE USE Protection with boundaries. Capture for a protective purpose An integrated service captures available device, session and activity signals for fraud prevention. Follow the stages to see how their purpose and access remain controlled. Captured: device / session · IP / browser · page / campaign · mouse activity B / ILLUSTRATED MISUSE Commercial reuse under another label. An extra copy at the point of capture In this hypothetical misuse, an actor obtains a secondary copy during collection. Access or parallel collection is an assumption of the illustration. Assumed extra branch: captured signals → secondary copy Hypothetical overseas processing and return under a different label Export → overseas processing → return New label: “audience insight”. Same accountability questions. both cards move through the same five stages. The records and routes are illustrative; the secondary copy, export, remapping and two-supplier CRM join are hypothetical. Neither timestamps alone nor Sigma reporting automatically expose raw fraud telemetry. Capture Device, session and activity information can help assess a transaction. Collection is only the start: each field has an origin, purpose and access boundary. Enrichment Adding purchase history, campaign context or inferred interests can make a customer record more commercially useful. Trace the purpose and authority for combining and reusing that information. Consequences A commercial segment and a fraud-risk marker are different things. Both become difficult to challenge when a recipient cannot explain the source, meaning and use of the information behind them.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Hypothetical overseas processing and return under a different label Export → overseas processing → return" ] }, { "id": "https://filmpass.nsstudio.uk/examples.html#technical-update", "heading": "Understand the mechanism. Ask for the record.", "text": "TECHNICAL QUESTIONS Understand the mechanism. Ask for the record. Four anonymous worked examples show the accessible fields, transformations and customer joins. Each gives you evidence to look for and a precise question to ask. Explore technical questions 20 questions: follow the flow Article 15 follow-up", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#context-lab", "heading": "What happens when the reason disappears?", "text": "INTERACTIVE EXAMPLE / THE SAME EVENT, A DIFFERENT MEANING What happens when the reason disappears? A refund, chargeback or valid redemption is not, by itself, evidence of consumer fraud. Explore how an incomplete record can become a misleading profile if a later rule treats the label as a finding. Choose a legitimate event A refund after a supplier cancellation A chargeback for non-delivery Several valid benefit redemptions Restore the missing context Illustrative mapping error · no real person or organisation is depicted in this example. 01 / ORIGINAL EVENT Supplier cancels an order The customer receives a refund because the supplier cannot fulfil the purchase. Reason: supplier cancellation · outcome: refunded 02 / DOWNSTREAM RECORD “Refund activity” The refund count travels onward without the cancellation reason. A later rule incorrectly treats it as customer abuse. Missing: cause, outcome and who was responsible 03 / POSSIBLE DECISION A restriction based on the wrong reason If a service relies on that label, it could refer, delay or refuse a later order. The customer sees the restriction, not the missing explanation. A risk label is an inference, not a finding of fraud Restoring the reason changes what a fair review can conclude. The recipient then checks the original event, its rules and the other relevant evidence. Same moment does not mean one shared payload. A checkout can trigger authentication, fraud checks, merchant analytics and order creation close together. These can be different messages, recipients and permissions. Matching may use an available order reference, customer identifier or a combination of fields; a millisecond timestamp can help correlate records but is not a universal identity key. Explore the matching conditions → The commercial value is in the context. A purchase can contribute amount, frequency, product and timing. A campaign tag may describe the route to the purchase. Combined with a usable customer reference, those fields can support segmentation. Payment reports, Sigma fields and raw internal fraud telemetry are separate data sources to trace. Follow capture, reporting and CRM matching → Related documentation: Stripe: merchant-defined metadata ↗ · Stripe: advanced fraud signals ↗", "sources": [ "https://docs.stripe.com/metadata", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#consequences", "heading": "A label can affect more than the original event.", "text": "WHY ACCURATE PROFILES MATTER A label can affect more than the original event. The route matters. A payment risk score, a merchant’s customer segment, a fraud-prevention database marker and an insurance record are separate systems. Effects arise when a decision-maker receives and relies on the relevant information. Follow the record into the decision Where the record is used How lost context can matter What establishes the connection Purchases, refunds & chargebacks In the example above, a legitimate claim for a refund or a non-delivery dispute is recoded as customer misconduct. A rule using that assumption could impose extra checks or restrictions. The dispute reason, final outcome, field mapping and the rule or person responsible for the later decision. Record which party the flag concerns. Banking access The Financial Ombudsman describes cases where incorrect fraud markers can prevent account opening, lead to account closure or affect mortgage applications. The actual marker, organisation that filed it and bank’s decision. FOS: fraud-marker complaints ↗ Insurance premiums In an FOS case study, an incident notification was wrongly recorded as a fault claim in the insurer’s records and the Claims and Underwriting Exchange. The customer was overcharged. FOS required corrected records, recalculated premiums and reimbursement. This is an insurance-data example; a payment-to-insurance connection would need its own evidence. Read the FOS case study ↗ SME access & customer relationships If inaccurate or unexplained information affects access to supply or a benefit scheme, an SME can face interrupted sales and difficult explanations to customers and members. The restriction notice, decision basis, contract, affected orders, expenditure and losses. Use the records for the event you are examining. Long after the payment. Different systems have different retention periods. Cifas’s published notice, for example, says some fraud or money-laundering risk information can be held for up to six years. That period relates to the Cifas database described in the linked notice. Cifas: processing, consequences and retention ↗ A closed case can leave an open data problem. A resolved dispute, corrected entry or refunded payment does not tell a person whether every recipient updated its copy. An audit should follow both the original record and any derived label, showing the source, status, review date and final outcome. ICO guidance emphasises accuracy, clear source and status, and the distinction between facts and opinions. ICO: accuracy of personal information ↗ A person may have no visibility of the record or practical control over a decision when it happens. Access, correction and complaint routes exist; making the responsible organisation identifiable is what makes those routes usable.", "sources": [ "https://www.financial-ombudsman.org.uk/consumers/complaints-can-help/fraud-scams/fraud-markers", "https://www.financial-ombudsman.org.uk/businesses/resolving-complaint/case-studies/consumer-complains-pricing-mistake-made-insurance-policy", "https://www.cifas.org.uk/fpn", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#three-d-secure", "heading": "3DS1 → 3DS2. More context for authentication.", "text": "THE TECHNOLOGY / WHAT CHANGED 3DS1 → 3DS2. More context for authentication. 3-D Secure helps the card issuer check whether an online purchaser is the legitimate cardholder. The move to EMV 3DS expanded the information and channels used in that process. It is an important part of the technical background to FilmPass’s research. 2016 The specification EMVCo’s history dates publication of its EMV 3-D Secure specification to 2016. EMVCo history ↗ 14 MAR 2022 The UK SCA deadline The FCA’s implementation deadline for strong customer authentication in e-commerce. SCA is a requirement; 3DS is a technology used to support it. FCA announcement ↗ 15 OCT 2022 Visa’s 3DS1 sunset Visa ended support for 3DS 1.0.2 in the regions covered by its notice, encouraging migration to EMV 3DS. The notice lists six country exceptions. Visa’s dated bulletin ↗ Authentication changed; purpose and accountability still matter Question 3DS1 / first generation 3DS2 / EMV 3DS What does it do? Authenticates a cardholder for an online card purchase. Retains that protective purpose with richer information for issuer assessment. What does the customer experience? Associated with browser-based authentication and password challenges that could interrupt checkout. Supports frictionless authentication or a challenge, such as a one-time code or biometric step, depending on the assessment and applicable requirements. Where can it operate? Designed around the original web-payment experience. Supports integrated browser and app flows, with non-payment authentication uses as well. What context can inform the check? A more limited first-generation authentication exchange. Richer transaction, payment, customer and device context can inform risk-based authentication. Actual fields depend on the version and implementation. Does authentication settle every question? Authentication and payment authorisation are different stages. Subsequent uses of customer information have their own purposes, recipients and conditions. Does it authorise CRM enrichment? A security protocol supplies a technical process, not a general permission for marketing reuse. Purposes, access, applicable law and the receiving system must be examined separately. Technical sources: EMVCo: channels, messages and privacy responsibilities ↗ · Visa: authentication, authorisation and the evolution of 3DS ↗ Why late 2022 matters. The migration helps frame FilmPass’s questions about the period leading into 2023. A deployment date, system version, changed field map or integration record can show what changed at a particular organisation. The industry milestone provides context; organisation-specific deployment and integration records supply the dates for the history being examined. Which collection system? 3DS authentication messages, Stripe.js advanced fraud signals, merchant analytics and CRM imports have different functions. UTM fields and mouse measurements in a SAR should be traced to their collecting system. Trace their source requests, identifiers and integration records. Stripe’s documentation distinguishes advanced fraud detection from basic device information used for 3DS2. Stripe: collection and 3DS2 distinction ↗", "sources": [ "https://www.emvco.com/why-emv/", "https://www.fca.org.uk/news/statements/deadline-extension-strong-customer-authentication", "https://www.visa.co.uk/content/dam/VCOM/regional/na/us/support-legal/documents/visa-will-discontinue-support-for-3ds.pdf", "https://www.emvco.com/emv-technologies/3-d-secure/", "https://corporate.visa.com/en/solutions/visa-protect/insights/3d-secure.html", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#across-borders", "heading": "A new label. The same questions.", "text": "FOLLOW THE RECORD ACROSS BORDERS A new label. The same questions. In this illustration, an overseas intermediary returns a customer-linked segment labelled “audience insight”. Its recipient sees the new label but loses the original context. The important question follows the record around the world: who collected it, changed it, received it and used it? COUNTRY A / ORIGIN Security result Collected for a stated protective purpose. → COUNTRY B / INTERMEDIARY Commercial repurposing In this story, an actor hides provenance and substitutes a new purpose. → COUNTRY A / RECIPIENT “Audience insight” A new label obscures the source; the underlying questions remain. Reveal the accountability questions + At the source Who authorised the export? Which record left, for what purpose, and what did the person understand? At the intermediary Which entity received it, what matching or enrichment occurred, and what transfer rules and contracts applied? On return Where is the provenance? Who uses the resulting segment, for which decisions, and how can an error be corrected? arrows show the illustrative route. Follow the identifiers, recipients, purposes and safeguards through each stage, including overseas processing and any return of enriched records. Multiple entities can make tracing an incident harder in practice. In this scenario concealment is the assumed conduct; no jurisdiction is presented as an automatic escape from scrutiny. ICO: responsibilities alongside international-transfer rules ↗", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/what-are-our-other-key-uk-gdpr-obligations-in-the-context-of-international-transfers/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#identity-trail", "heading": "Many names. One traceable chain of responsibility.", "text": "FOLLOW THE LEGAL PERSON / FOLLOW THE PROCESSING Many names. One traceable chain of responsibility. A brand on a website, an old name in terms, a trading nickname in an email and a different name on an invoice can make the same relationship hard to follow. Recording the legal entity and registration number at each step helps an SME, adviser or regulator reconnect the chain. Trace the name at the relevant date. A customer-facing brand, registered company name and group name can be different. Keep the company number, contract date, invoice and applicable privacy notice together. A later name should not overwrite the earlier role in your understanding of the history. Compare the original dated document with the name history. Read a company identity trail → A new name does not erase the old obligations. Section 81 of the Companies Act 2006 provides that changing a company’s name does not affect its rights or obligations or invalidate legal proceedings involving it. A brand change and a transfer to a different legal entity are different events. For group accounts, also distinguish the company whose record hosts a filing from the entity whose accounts the document contains. Keep the exact number, period and document title together. Companies Act 2006, section 81 ↗ Follow the corporate record changes → An end-to-end identity trail What appears to the customer What to connect behind it The useful supporting record Brand, domain or nickname Full legal name, company number, role and relevant date. Terms, invoice, merchant confirmation and register entry. Keep a brand separate from its owner, supplier and payment provider. Legacy name in a contract or technical schedule The legal person at signing and any later assignment, novation or name change. Signed agreement, amendments, entity identifier and effective dates. A stale label raises a tracing question; the document determines its significance. A claimed global presence Whether each address is an operating office, registered office, service address or virtual-office facility. Dated register records and address-service evidence. Classify an address from evidence rather than assuming an office means staff or servers are there. Overseas processing The actual recipient, controller or processor role, processing activity and applicable jurisdiction. Recipient and subprocessor lists, agreements, transfer records and access logs. These records identify where information is processed and who can access it. Group invoices or renamed reporting fields Who supplied the service, received funds, received data and made the decision. Separate payment reconciliation from data provenance, then connect them with references and dates. Virtual offices and different privacy regimes require precise descriptions. A service address can be legitimate: UK guidance permits an appropriate registered office supplied by an accountant, solicitor or agent. Different countries’ rules can complicate investigation, but neither an overseas address nor a rebrand makes an identifiable person’s data anonymous or removes applicable responsibilities. A claim that a particular location is only virtual needs evidence about that location. GOV.UK: registered office requirements ↗ · ICO: responsibilities alongside transfer rules ↗", "sources": [ "https://www.legislation.gov.uk/ukpga/2006/46/section/81", "https://www.gov.uk/limited-company-formation/company-address", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/what-are-our-other-key-uk-gdpr-obligations-in-the-context-of-international-transfers/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#transparency-actions", "heading": "A closed user group should not mean a closed explanation.", "text": "FOR CONSUMERS, SMES, BRANDS & BENEFIT MEMBERS A closed user group should not mean a closed explanation. Employee, membership and key-worker benefits can connect a brand, a platform, a supplier and a payment service. A person using the benefit needs a clear route to the organisation that can explain a decision. Here, “closed user group” means an eligibility-based benefit scheme; it is not another name for a fraud-prevention database. Who is responsible? Identify the supplier, platform operator, merchant and organisations deciding each data purpose. Show the legal names behind the brands and provide a contact that can route a complaint. What informed the decision? Explain the category, source, date and use of the relevant information, subject to applicable limits. Distinguish a supplier restriction, an eligibility rule, a security check and a marketing segment. How does a correction travel? Give a route to challenge an error, review the decision and reach recipients of corrected information. Record the outcome so an outdated label does not keep being treated as current. When a record about you appears wrong. Pinpoint the event. Keep the transaction reference, decision date, relevant correspondence and what actually happened. Request the record and its meaning. Ask the relevant organisation what personal information it used, where it came from and which decision it informed. Applicable exemptions can limit disclosure. Explain the correction. Identify the inaccurate or incomplete field and provide the evidence and outcome that should accompany it. Address ongoing use. Where the right applies, ask for restriction while accuracy is checked and ask how relevant recipients will be informed. Keep the response in the chronology. If unresolved, use the organisation’s complaint route and the appropriate regulator or ombudsman route for that organisation and issue. Rights and exceptions depend on the processing and applicable law. These links explain the current UK routes; a request is not a guarantee that all data must be erased. ICO: getting information corrected ↗ · ICO: restricting use ↗ · FOS: complaints about financial firms’ fraud markers ↗ THE PERSON AND BUSINESS BEHIND THE RECORD A useful safeguard should remain explainable. The practical lesson is straightforward: a person or SME needs a traceable record, an accountable decision-maker and a workable way to correct mistakes. Explore closed-group transparency → Data-law update: follow the purpose and the actual use → Legislative context checked 21 October 2026.", "sources": [ "https://ico.org.uk/for-the-public/your-right-to-get-your-data-corrected/", "https://ico.org.uk/for-the-public/your-right-to-limit-how-organisations-use-your-data/", "https://www.financial-ombudsman.org.uk/consumers/complaints-can-help/fraud-scams/fraud-markers" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#section-10", "heading": "Keep the distinctions clear.", "text": "QUICK ANSWERS Keep the distinctions clear. Is fraud prevention itself the concern? The concern explored here is how information collected for fraud prevention can be reused, lose its original context or contribute to misleading decisions about a person or business. How does the explanation relate to FilmPass? Our experience prompted the research. This public edition explains the mechanisms through worked examples. Original correspondence, disclosures and case records are preserved privately while we follow the relevant processes. Is one timestamp a universal key to a person? No. Closely timed events can help correlation, but reliable matching depends on available identifiers, clock precision, system context and access. Several messages can arise during one checkout without every recipient receiving the same data. Does 3DS2 make fraud data available for marketing? No. EMV 3DS supports authentication. Advanced fraud telemetry, transaction reporting and merchant CRM integrations are separate functions. A reuse route can be examined through its fields, access, transfer, matching and purpose. Can a risk record affect banking or insurance? Official Financial Ombudsman material describes harm from incorrect fraud markers and an insurance case involving a wrongly recorded claim. These are distinct systems. The page identifies the mechanism and source for each system separately. Does overseas processing make information “clean”? Follow the recipient, data, purpose and safeguards across changes of country, field name or commercial label. The overseas-return animation illustrates those accountability questions. What makes this guide useful to search and AI systems? Readable HTML, labelled examples, dates, source links and structured metadata help systems interpret the material. The evidence and explanation use the same wording in the page and metadata. Public discovery depends on publication and a crawler’s choices; this private edition is not publicly indexed. Primary sources reviewed 9 October 2026. Technical descriptions concern the versions and sources specified; later guidance does not determine earlier events.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/examples.html#section-11", "heading": "Two more ways to test the explanation.", "text": "Two more ways to test the explanation. Can the record be matched? Change the identifier, receiving lookup and account scope to explore the technical matching conditions and the separate purpose question. Try the matching example → Can the money trail be reconciled? Reveal the supporting references behind fictional invoice, settlement and intercompany entries. Trace data separately. Try the accounting example →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html", "title": "20 technical questions", "sections": [ { "id": "https://filmpass.nsstudio.uk/technical-questions.html#section-1", "heading": "Technical questions and worked examples.", "text": "UNDERSTAND THE SYSTEM / ASK A PRECISE QUESTION Technical questions and worked examples. Understand what connected systems could do, then test the explanation against the records. Explore 20 practical questions and four interactive examples of collection, access, transformation, matching and later use. Explore 20 questions Try four examples Business capacity Who must answer? Privacy policy or personal records? Primary sources Reading guide ↗ Turn an explanation into a question. Turn an explanation into a question. EXPLANATION → MECHANISM → CONDITIONS → SUPPORTING RECORDS. Ask what is possible, what is required and what happened. EXPLANATION MECHANISM CONDITIONS SUPPORTING RECORDS Ask what is possible, what is required and what happened. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Turn an explanation into a question. EXPLANATION → MECHANISM → CONDITIONS → SUPPORTING RECORDS. Ask what is possible, what is required and what happened. EXPLANATION MECHANISM CONDITIONS SUPPORTING RECORDS" ] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#technical-faq", "heading": "What does the explanation leave unanswered?", "text": "20 QUESTIONS / FOLLOW THE FLOW What does the explanation leave unanswered? Start with the answer you were given. Explore what the connected systems could do, the conditions needed and the records that would test the explanation. Follow the information through collection, access, transformation, matching and later use. A statement about one category of data may leave another route unexplained. For example, protected fraud signals and a separately collected merchant record can concern the same checkout. Trace each branch. 1 · Possible mechanism 2 · Conditions needed 3 · Records to examine 4 · Question and next step The routes below are illustrative technical investigations. Source links support the building blocks and relevant rights; a particular organisation's configuration and records establish what happened in its case. Each answer explains what the evidence could support and what remains unresolved. Use the personal-records request for information about you. An SME's supplier review or technical support enquiry is the route for wider configuration and integration evidence; access rights do not guarantee every internal document. Start with the event, reference and date you already have. Try four interactive examples ↓ Personal-records request ↓ Find a question or mechanism All 20 Collection & reuse Records & identity Access & responsibility Understanding replies Decisions & evidence 20 of 20 questions shown Open shown answers Close shown answers Clear filters No matching questions. Try a shorter search or use Clear filters above. 01 They sent me their policy. What does it leave unanswered? Test the general explanation against a particular record and its destinations. The possible mechanism A checkout event can enter an order system and also trigger a configured connection. The receiving system may store selected fields under different names. A statement about collection alone leaves those later steps unresolved. Start with one event you can identify and reconstruct its route. Checkout event Selected fields Configured destination Later use What needs to be present The additional route needs an enabled connection, accessible fields and a receiving system. A policy category alone establishes none of these. Records to examine Your event, order or payment reference and date The relevant destination and field mapping A corresponding receiving record or delivery entry A question you can adapt For the event identified in my request, please explain which records were created, which fields went to each recipient, what was derived from them and how the resulting records were used. Please relate your policy explanation to those records. Copy this question What to do next Put the response beside a four-column route: source, fields, destination, use. Follow up on the first missing step with the event reference. How to read the evidence A mapped receiving record supports that connection. A general description leaves the connection unresolved; it does not establish that a transfer occurred. Personal records and policy replies → Link to question 01 Configured destinations ↗ Personal records and supporting information ↗ 02 They call this business data. What about the personal records within it? Personal data stays personal when the transaction is for a business. Trace whose activity each record describes. The possible mechanism Information relating to an identifiable person is personal data even when that person acts for a business. In this stock-purchase example, Person A works from home; the configured fraud tool records browser and mouse-activity information from A’s session. The payment carries Person B’s cardholder name and billing address. The stock is for Company C. Those are separate sources and roles. B’s billing address does not establish A’s location or who performed the session activity. Home checkout session Browser and activity records Separate cardholder and billing details Joined records and assessments What needs to be present Establish how each record is linked to a person. Mouse-activity collection belongs to the fraud tool in this example; it is not a universal 3DS2 field. Authentication alone does not identify who physically operated every device. Records to examine Account/session keys linking browser and activity records to the checkout user Separate cardholder, billing-address and authentication information Whose profile received the linked activity or resulting assessment A question you can adapt The checkout user and named cardholder were different people. Please distinguish my browser/session activity from the cardholder and billing details. How were those records linked, whose profile received the resulting assessment, and was the billing address treated as my location? Please address my identifiable activity separately from company-only records. Copy this question What to do next Start with an order where the checkout user and cardholder differ. Compare the session reference, named account, payment reference and address fields, then trace the receiving profile. Ask which location was supplied, observed or estimated. How to read the evidence A business label does not remove personal-data status. Verified links establish whose information is involved; an unsupported assumption that the cardholder operated the checkout should be challenged. Personal data and different cardholder identities → Link to question 02 What is personal data? ↗ Identifiers and customer traits ↗ Advanced fraud collection ↗ Device context and separate authentication ↗ 03 Could information collected during fraud prevention acquire another use? Investigate parallel collection and accessible results as separate routes. The possible mechanism There are two routes to test. A receiving system could use an accessible assessment result for another purpose. Alternatively, the merchant could separately send its own order or claim fields into a customer system. The second route does not require the fraud provider's protected raw signals to leave that provider. Same checkout Separate merchant record Connector or calculation New customer attribute What needs to be present The destination needs access to the relevant fields or output. It also needs a configured rule and, for a person-level profile, a usable matching key. Records to examine Separate collection requests and their field lists Accessible result fields and connector permissions Receiving attributes, purpose and creation time A question you can adapt Please distinguish protected raw fraud signals, assessment outputs and separately collected merchant information. Which of those entered any reporting, customer-profile or marketing system, through which connection and for what use? Copy this question What to do next Trace each branch separately. A reply about raw fraud signals should be followed by a question about merchant-held fields and derived outputs. How to read the evidence An enabled, evidenced branch supports that route. A restriction on one category does not describe every branch, and a possible branch is not evidence that it operated. Compare the four field-level examples → Link to question 03 Advanced fraud collection ↗ Merchant-visible risk outcomes ↗ Configured destinations ↗ 04 How do I investigate the merchant/payment-provider blame loop? Follow the references across each hand-off. The possible mechanism A merchant can create a payment request containing a reference to its order. A provider can return a payment identifier and later send an event notification, often called a webhook. Another system may process that notification. Each participant can describe one stage while leaving the hand-off unexplained. Order reference Payment request Provider response or event Merchant action What needs to be present The references must correspond to the same transaction and account. Notifications must reach an enabled endpoint and be processed to produce the later action. Records to examine Order and payment reference correspondence Relevant request, response and event identifiers Delivery status and receiving-system action A question you can adapt Please identify the records and decisions within your responsibility for this transaction. Which reference connects them to the other organisation's records, what did you send or receive, and which organisation controls the next processing step? Copy this question What to do next Send each organisation the same transaction reference and ask about its own hand-off. Compare the descriptions for missing or conflicting steps. How to read the evidence Matching records can establish a hand-off. They do not automatically mean both organisations controlled every later use. A traceable set of responsibilities → Link to question 04 Order references and metadata ↗ Event notifications and delivery ↗ Roles for each processing activity ↗ 05 Can one checkout create several connected payloads? One customer action can produce several messages with overlapping information. The possible mechanism A payload is the information carried in a message. An order submission, authentication request, device-signal request and analytics event can be separate messages. Common references can connect them even when their fields differ. A browser view may show the first requests while later server-to-server transfers need separate records. Checkout action Separate requests Shared references Later server events What needs to be present Each branch requires its own integration. Matching requires reliable references and context, not just similar timing. Records to examine Request destination, event type and field list Order, payment, session and event identifiers Server delivery records for the later stages A question you can adapt For this checkout, please identify the separate collection and transmission processes, the fields each carried and the references connecting them. Which later transfers occurred between servers and would not appear in the customer's browser? Copy this question What to do next Draw the branches and give each message its own reference. Keep collection, delivery and subsequent use as separate entries. How to read the evidence A browser request shows that request's destination and contents. It cannot, by itself, establish every onward transfer or the recipient's later use. One customer journey, several records → Link to question 05 Advanced fraud collection ↗ Events and their properties ↗ Event notifications and delivery ↗ 06 What could they know that I never explicitly told them? Recorded events can become calculated attributes and inferred labels. The possible mechanism In an illustrative reward system, three claims within a month could be counted and turned into a 'repeat redeemer' attribute. A further rule could place the account in an offer audience. The attribute is a calculation about recorded activity; it is not something the customer typed into a form. Claim events Frequency calculation Stored attribute Audience rule What needs to be present Events must be collected, correctly associated with an account and processed by a calculation or classification rule. Records to examine Observed events and their identifiers Stored calculated or inferred fields Rule version, calculation date and audience membership A question you can adapt Please include information observed or inferred about me, including calculated attributes, scores and segments. Please explain the source records, meaning and date of those attributes, and how they were used. Copy this question What to do next Compare the disclosed profile with the source events you recognise. Ask separately about a missing calculation or a label that appears unsupported. How to read the evidence A stored attribute establishes that output. The input events and rule are needed to assess whether its calculation and interpretation are sound. Reward fulfilment and derived attributes → Link to question 06 Events and their properties ↗ Identifiers and customer traits ↗ Observed and inferred information; intelligibility ↗ 07 Could 'not shared' overlook access through a dashboard, API or export? Name the access method and the fields instead of relying on a broad verb. The possible mechanism A person can view information in a dashboard, a program can retrieve it through an API, or a report can download selected fields. An automated connection can then forward accessible information. These are different mechanisms to examine; they do not all expose the same fields. Available account fields View, query or export Receiving user or system Further use What needs to be present The user or integration needs permission to access the fields. A documented download feature does not establish that a particular export ran. Records to examine Field availability and access roles Relevant query, export or access entries Destination and receiving record A question you can adapt Does your answer cover dashboard visibility, API retrieval, report downloads and automated connections? For each applicable method, please identify the fields, permitted recipients and any relevant records of actual access or delivery. Copy this question What to do next Break a general denial into separate questions about each access method. Use the actual field names where available. How to read the evidence Permission establishes capability. A query, export or delivery record can establish use of that capability within its recorded scope. What an export can establish → Link to question 07 Reporting and CSV exports ↗ Access and data sharing ↗ 08 What changes when a merchant buys additional tools? Check the account's actual entitlement and permissions at the relevant date. The possible mechanism Plans and roles can change which results are exposed. Stripe, for example, documents risk scores available on certain Radar plans. A merchant might use an exposed output in its own workflow. That is a different question from whether it can retrieve the provider's underlying device and activity inputs. Account entitlement Exposed result Authorised query Configured workflow What needs to be present The particular account and role need the relevant entitlement. The integration must request and process the field. Records to examine Historical plan and role permissions Actual API response or report schema Integration configuration and result-field mapping A question you can adapt At the date concerned, which results could this account and its connected applications access? Please distinguish those exposed outputs from the raw inputs, and identify whether any output was passed to another workflow. Copy this question What to do next Compare the historical configuration with the explanation you received. Current product documentation cannot establish an earlier account's settings. How to read the evidence An exposed field makes a route possible. Evidence of retrieval and downstream handling is needed to establish what happened next. Selected risk-result example → Link to question 08 Merchant-visible risk outcomes ↗ Reporting and CSV exports ↗ 09 Can information become difficult to recognise after it moves? Follow the meaning of a field through its transformation. The possible mechanism A configured function can rename a field, combine values, add context or output a category. In an illustrative rule, a claim count could become a repeat-use label. Searching the destination only for the original field name would miss that output. The mapping explains how the two records relate. Source field Transformation rule New field or category Destination record What needs to be present The function must receive the source field, execute the relevant rule and deliver its output to the destination. Records to examine Before-and-after field names and meanings Transformation version active at the time Output record and preserved source reference A question you can adapt Please identify derived or renamed fields created from the relevant source records. What transformation produced them, what do they mean, and which destination records retain those outputs? Copy this question What to do next Build a source-to-output dictionary. Search the resulting names and categories as well as the original names. How to read the evidence A matching name alone is weak evidence. A recorded transformation and corresponding input/output provide a stronger connection. Transformations and provenance controls → Link to question 09 Transforming destination events ↗ 10 Can a record still connect to me after my name disappears? Look for the surviving key and the information needed to use it. The possible mechanism A customer reference can replace a name in an export. If the recipient has a corresponding lookup, it may reconnect the record to a person. A hashed value may also support matching under the relevant conditions. Removing a visible name does not describe what matching information remains available. Named record Token or reference Available lookup Reconnected record What needs to be present The identifier must be usable in the recipient's account context and the necessary matching information must be available. A campaign label is not necessarily a unique person key. Records to examine Identifiers retained after the transformation Who holds the corresponding mapping Matching rules, account scope and resulting record A question you can adapt Which identifiers or distinctive attributes remain, and who can access the additional information needed to link them to a person? Please explain whether and how the receiving system performed that match. Copy this question What to do next Test one known reference against its corresponding receiving record. Check collisions, shared accounts and mistaken matches. How to read the evidence A verified lookup supports linkability for that recipient. A theoretical lookup that the recipient cannot reasonably obtain does not establish the same position. Try the matching conditions → Link to question 10 Pseudonymisation and identifying information ↗ Identifiers and customer traits ↗ 11 Could 'nothing found' mean they searched the wrong place or identifier? Separate the search result from the question of what records exist. The possible mechanism An account may be linked through an old email, internal customer key, payment reference or device/session identifier. A search against one visible field may miss records stored under another. Related information can also sit in an archive or with a service processing it on the organisation's behalf. Known reference Related identifiers Relevant systems Search result What needs to be present A relationship between the identifiers must exist. Search scope should reflect the request and a reasonable, proportionate retrieval effort. Records to examine Known references, aliases and date range Systems and identifiers covered by the search Distinction between absent, deleted and withheld information A question you can adapt Please clarify whether the information was never collected, deleted, not located or withheld. Did the search cover the supplied references, related identifiers and relevant information held on your behalf? Please explain any remaining gaps. Copy this question What to do next Provide a concrete receipt, event reference or disclosed identifier and ask for a targeted search. Keep the earlier answer and the follow-up together. How to read the evidence A documented search explains its coverage. A missing result does not prove either that a record never existed or that it is being concealed. Adapt the personal-records request → Link to question 11 Finding and retrieving information ↗ Personal records and supporting information ↗ 12 What could an unexplained code conceal about the record's use? A value needs its definition, subject and operational meaning. The possible mechanism An invented value such as category_3 could represent a segment, processing state or reason code. The same number may mean something different in another table or software version. A downstream rule could use the value to select an offer or trigger review even when the export provides no explanation. Stored code Versioned definition Rule consuming the code Resulting action What needs to be present The code needs a defined meaning in that system and a rule or process that uses it. Its appearance alone does not reveal the action. Records to examine Field definition and relevant version What the classification describes Any action or segment associated with it A question you can adapt Please explain the unfamiliar fields and codes in my disclosure, including what each describes, when it was assigned and how it was used. Where meanings changed, please provide the meaning applicable to these records. Copy this question What to do next Make a small table of unexplained fields and example values. Ask for each definition, then compare the explanation with the resulting activity. How to read the evidence A dictionary explains the code. An action record is needed to establish that the code affected this particular outcome. Ask for an intelligible disclosure → Link to question 12 Observed and inferred information; intelligibility ↗ 13 Could a transaction score become a broader label about a person? Check whether a payment-level assessment was promoted into a customer attribute. The possible mechanism In an illustrative receiving workflow, a payment's risk result could be copied into a customer table and used in a rule about future transactions or offers. This changes the level at which the result is applied. A prediction about one payment does not establish a person's general behaviour or commercial value. Payment assessment Customer-key join Profile attribute Later decision What needs to be present The result must be accessible, the customer join must work and a downstream rule must consume the copied or derived value. Records to examine Original result, subject and timestamp Customer-field mapping and update history Later rule inputs and resulting action A question you can adapt Was this assessment used only for the original payment, or copied into an account or customer profile? Please identify any derived labels and subsequent decisions that used it, including their dates and purposes. Copy this question What to do next Compare the original assessment with later profile values. Check whether a correction or expiry affected the copied attribute. How to read the evidence The full input-to-action chain supports a later use. A score's presence in an export alone does not establish that it drove a subsequent decision. Accessible result and later-use example → Link to question 13 Merchant-visible risk outcomes ↗ Identifiers and customer traits ↗ 14 What happens when the event survives but its explanation disappears? Trace which context was dropped before a label was assigned. The possible mechanism An illustrative export could retain 'refund' while omitting 'supplier cancelled the order'. A later rule might count the remaining events as customer behaviour. Similar errors can arise when retries are counted as new purchases or records from different people are joined. The source event and receiving interpretation need comparison. Event with explanation Reduced export Classification rule Incomplete label What needs to be present Relevant context must be absent or misinterpreted and the later rule must depend on the remaining fields. Records to examine Original event and cancellation reason Fields retained or omitted in the receiving record Classification and correction history A question you can adapt Please compare this label with the source event and its recorded reason. Was relevant context omitted or misinterpreted? Please correct inaccurate facts, complete missing context and explain which recipients or derived records were addressed. Copy this question What to do next Supply the cancellation or other source record. Follow the correction into the receiving profile rather than stopping at an acknowledgement. How to read the evidence An event mismatch can identify a specific error. A disputed opinion still needs examination of its supporting facts and how it is recorded. What happens when the reason disappears? → Link to question 14 Accuracy and context ↗ Challenging inaccurate or incomplete records ↗ 15 Was there meaningful review, or just a person repeating an automated result? Separate the original action from the later support response. The possible mechanism A rule or model output can trigger an action before a support employee sees the case. A later message may repeat the recorded outcome without revealing how it was produced. Investigate the original trigger and the review as two events, including whether the reviewer had the evidence and authority to change the outcome. Inputs and rule Original action Review evidence Review outcome What needs to be present Establish which stages were automated and what a person actually did. A support job title alone does not answer this. Records to examine Original trigger and action time Information considered in the review Review conclusion and any override or correction A question you can adapt Please explain how the original decision was made and what happened during the subsequent review. What evidence did the reviewer consider, could they change the outcome, and what decision did they independently reach? Copy this question What to do next Create separate timeline entries for the initial action and review. Ask about unexplained intervals or a review that does not address the disputed evidence. How to read the evidence A documented reconsideration can show what the review covered. A templated response alone leaves that process unexplained. Correction and challenge → Link to question 15 Merchant-visible risk outcomes ↗ Personal records and supporting information ↗ 16 What does 'legitimate interests' explain about the actual flow? Attach the claimed purpose and basis to each actual use. The possible mechanism One source event can feed different processes: fulfilment, security assessment, reporting and a later customer segment. Giving the whole journey a broad label does not identify what each process does. Build a map connecting the fields and recipients to their actual purposes before assessing the explanation. Source fields Processing step Recipient and purpose Claimed basis What needs to be present Identify the actual use, applicable date and precise basis. Ordinary legitimate interests and recognised legitimate interest have different requirements. Records to examine Purpose and basis for each identified use Date and explanation of any further-purpose assessment Recipient's actual use of the received fields A question you can adapt Which precise lawful basis and purpose apply to each processing step identified here? Please address any later matching, enrichment or reuse separately and explain the basis applicable at the relevant date. Copy this question What to do next Mark where the purpose changes on the route. Follow up on a basis that is stated only for collection but leaves the later use unexplained. How to read the evidence A specific explanation can be assessed against the records. Repeating a general basis leaves that comparison incomplete. Source purpose and later use → Link to question 16 Further purposes ↗ Ordinary legitimate interests ↗ Recognised legitimate interest ↗ 17 What else might run alongside payment authentication? Inventory the separate collection processes around the checkout. The possible mechanism Authentication, advanced fraud collection and a merchant's own event tracking can run through distinct integrations. A statement about authentication does not describe every request made around the same visit. Some activity may happen on other pages or through later server events. Establish which process generated each record. Customer visit Separate integrations Distinct field collections Respective destinations What needs to be present Each integration must be present and active in the relevant configuration. Collection scope and timing differ between systems. Records to examine Relevant scripts and enabled integrations Request destinations, fields and collection timing Server-side processing that follows the visit A question you can adapt Please distinguish authentication data from advanced fraud signals, merchant analytics and other event collection. Which integrations were active, what did each collect, and which subsequent server-side transfers used those records? Copy this question What to do next Keep a separate line for each integration. Ask whether the explanation covers only the payment step or the wider visit and subsequent processing. How to read the evidence A request capture establishes a particular collection event. Similar timing does not establish identical payloads or shared purposes. Collection, merchant context and reporting → Link to question 17 Advanced fraud collection ↗ EMV 3DS authentication ↗ Events and their properties ↗ 18 Could a profile survive after the original account or record is removed? Check deletion and correction across copies and derived attributes. The possible mechanism An operational account, a receiving customer record and a derived segment can have separate lifecycles. Removing the first does not by itself demonstrate what happened to the others. Deletion and suppression tools have specific coverage, so each destination and any continuing event collection need checking. Account closure Deletion or suppression request Destination handling Remaining attributes What needs to be present A separate copy or derived record must have been created. What survives depends on retention rules, tool coverage and destination processing. Records to examine Categories deleted and categories retained Destination notifications and completion records Retention reasons and continuing collection settings A question you can adapt Please distinguish account closure from deletion and suppression. What records or derived attributes remain, for how long and why? Which destinations were notified, and what confirms that the relevant deletion or correction was completed? Copy this question What to do next Compare the answer across the source and receiving organisations. Ask about surviving identifiers and renewed collection, as well as visible account access. How to read the evidence A completed action establishes its stated coverage. It does not establish deletion from systems outside that coverage. Personal records, recipients and retention → Link to question 18 Deletion and suppression coverage ↗ Finding and retrieving information ↗ 19 Could reward fulfilment also generate commercially useful information? Trace the claim into reporting, segmentation and the commercial arrangement. The possible mechanism In an illustrative rewards service, a valid claim supports fulfilment and a per-claim fee. The same account-linked events could also be counted, categorised and used to select a later offer. The fee and the information flow are separate things to examine; a fee alone does not reveal the use of the resulting records. Reward claim Fulfilment and fee record Account-linked calculation Offer selection What needs to be present The secondary use needs accessible claim fields, a matching identifier and a configured calculation or audience rule. Records to examine Claim fields and account identifiers Derived categories and audience memberships Fee definition and the services it pays for A question you can adapt Beyond fulfilling and charging for the claim, were its fields used to derive customer attributes, build audiences or select offers? Please identify the relevant records, recipients and purposes, and explain separately what the claim fee purchases. Copy this question What to do next Follow one claim into both the settlement record and the customer record. Compare the commercial description with the operational uses. How to read the evidence A receiving segment can establish profiling activity. A settlement fee on its own does not establish a data sale or that profiling occurred. Reward fulfilment example → Link to question 19 Events and their properties ↗ Identifiers and customer traits ↗ 20 How do I establish whether the route actually operated? Connect capability, configuration, delivery, receipt and use. The possible mechanism A feature can exist without being enabled. An enabled connection can fail, filter out an event or deliver data that the recipient does not use. Trace a specific event through each stage. Compare both ends and account for retries, duplicates and transformations before treating them as one completed chain. Configured capability Event delivery Receiving record Subsequent use What needs to be present The records must correspond to the same event and relevant account context. Logs need enough coverage to support the conclusion being drawn. Records to examine Configuration and permissions at the relevant date Delivery attempt, result and event identifiers Matching receiving record and resulting action A question you can adapt Please identify the records connecting this source event to its destination and subsequent use. Which stages are confirmed, failed, filtered or unrecorded, and what evidence supports each part of the explanation? Copy this question What to do next Maintain a short evidence table: stage, record, source, confirmed fact, unresolved question. Investigate the first unsupported connection. How to read the evidence A matched chain supports a specific route and use. Failed delivery or a different recipient can rule out that proposed route. An unexplained gap remains a question, not a finding of intent. Trace a transfer through its records → Link to question 20 Event delivery visibility ↗ Event notifications and delivery ↗ Download all 20 questions and explanations Search and copying run in this page. No question or search is sent anywhere.", "sources": [ "https://www.twilio.com/docs/segment/connections/destinations", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/what-is-the-right-of-access/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-is-personal-data/", "https://www.twilio.com/docs/segment/connections/spec/identify", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://www.emvco.com/knowledge-hub/supporting-the-deployment-of-emv-3-d-secure-solutions/", "https://docs.stripe.com/radar/transaction-risk-prevention", "https://docs.stripe.com/metadata", "https://docs.stripe.com/webhooks", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/how-do-you-determine-whether-you-are-a-controller-or-processor/", "https://www.twilio.com/docs/segment/connections/spec/track", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/how-can-we-supply-information-to-the-requester/", "https://stripe.com/sigma/pricing", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/data-sharing-covered-by-the-code/", "https://www.twilio.com/docs/segment/connections/functions/insert-functions", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/how-do-we-find-and-retrieve-the-relevant-information/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/", "https://ico.org.uk/for-the-public/your-right-to-get-your-data-corrected/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/purpose-limitation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/legitimate-interests/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/recognised-legitimate-interest/", "https://www.emvco.com/emv-technologies/3-d-secure/", "https://www.twilio.com/docs/segment/privacy/user-deletion-and-suppression", "https://www.twilio.com/docs/segment/connections/delivery-overview" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#technical-records", "heading": "How the same information acquires a different purpose.", "text": "WORKED EXAMPLES / FOLLOW THE FIELDS How the same information acquires a different purpose. A statement that internal fraud telemetry is not shared can be accurate about that dataset and still leave questions about other records unanswered. A merchant may hold overlapping checkout facts, receive selected risk results, or send its own events through a separate connector. Follow those fields into the receiving system to establish what was actually copied, inferred and used. The technical hinge is the accessible field and its destination. A new name can obscure the origin of a record. It does not change the underlying facts, make a person unidentifiable or establish permission for a new use. ILLUSTRATIVE RECORDS · ANONYMOUS ACTORS · NO LIVE CONNECTIONS These four scenarios are constructed examples. The references below explain the individual technical building blocks. All identifiers, amounts, labels and rules in the interactive tool are invented. No raw processor telemetry is exported in this demonstration. 01 / PARALLEL COLLECTION A second route from checkout 02 / DERIVED RESULT A risk result becomes a flag 03 / IDENTIFIER MATCH A token reconnects records 04 / REWARD CLAIM A claim becomes a segment A parallel copy of merchant-held fields Follow a fictional merchant event through access, transformation, matching and use. Connector enabled Receiving lookup exists Retain source and mapping 1 · Record 2 · Access 3 · Transform 4 · Match 5 · Use The starting record Select a stage to see what changes. Original accessible record Record at the selected stage Stage 1 of 5 Previous Next Reset all What would establish this route? The question to ask The switches test a particular technical route. Turning off its lookup does not establish anonymity; turning on a connector does not establish lawful reuse. Source records remain held when a downstream route is stopped. Four different mechanisms behind similar commercial labels Starting information Illustrative mapping What the label leaves unanswered Merchant product and campaign fields product_category → interest_hint Was this a separate collection of merchant data? A purchase fact is being turned into an inference. An accessible payment risk result risk_level → offer_candidate Which result was disclosed, and who chose to use it for offers? A risk score is not a validated measure of customer value. Partner records with a shared token member_token → profile_ref Who issued the token and held the lookup? A shared payment provider does not itself establish this join. Valid reward claims claim_count → redemption_band Where did fulfilment or duplicate checking become segmentation? A per-claim service fee alone does not show a data sale. Where the copy is made matters. A merchant-controlled event can branch before reaching a payment service. Separately, a merchant can transform a result returned by that service. These routes have different origins: copying merchant inputs is not extracting the processor’s private inputs. A plugin cannot read a cross-origin payment frame or private server records merely because it is present on the page; any such access needs its own demonstrated mechanism. Ordinary event middleware can transform fields and forward events to configured destinations. That capability makes the examples technically plausible. To establish an actual route, inspect the deployed configuration, permissions, event samples and receiving logs for the relevant period. Technical reference T3 . What an export can and cannot establish. Payment platforms document merchant-visible risk outputs and reporting/export tools. The accessible schema, account scope and product entitlement determine what a particular export can contain. An export facility does not establish access to every raw signal that contributed to a score. T1 · T2 · T5 . A verified row leaving a system establishes that row’s transfer. A later profile with the same customer reference can support a connection, but the mapping and import history are needed to establish how its fields were produced. Similar totals, close timestamps or similar labels alone do not identify the route. A new field name can hide a meaningful change. Changing risk_level into offer_candidate is more than moving a column if the receiving business uses it to choose offers. Conversely, copying an order reference into a CRM for customer support may remain part of the original service. The destination software’s name does not settle the purpose; examine the actual operation and decision. Current ICO guidance requires assessment of further use under purpose limitation and an appropriate lawful basis. Renaming, pseudonymising or moving data abroad supplies no automatic permission. L4 . Why removing a name may leave a person identifiable. In example 03, the receiving organisation holds the token-to-profile lookup. It can therefore reconnect the record to a person. A recipient without that lookup must be assessed separately, including other reasonably available ways to identify someone. Hashing an email or replacing it with a token is not, by itself, proof of anonymity. L5 . Customer tools can associate a user identifier with attributes and send them to configured destinations. This documents a general integration capability, not access to another merchant’s customers. T4 . THE QUESTION THAT CROSSES THE LABEL “Which source fields produced this record about me, which identifiers connect it to me, who received it, and what was it subsequently used to decide?” Access through a dashboard or API is still access. The ICO’s controller-to-controller sharing code includes making data available through IT systems. Processing on a controller’s behalf and movement within one controller are distinct arrangements, with their own obligations. L3 .", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#business-capacity", "heading": "Personal data stays personal in a business transaction.", "text": "COMMON REPLY 01 / “YOU WERE ACTING FOR A BUSINESS” Personal data stays personal in a business transaction. “Business capacity” does not remove personal-data status. Information relating to an identified or identifiable living person is personal data. Start with the information, its context and the person it relates to. A stock purchase for a company does not turn a named user’s account activity into company-only information. L8 · L9 . WORKED EXAMPLE / THREE DISTINCT ROLES The purchaser, the cardholder and the company. Person A works from home and places a stock order for Company C using a card issued in Person B’s name. In this example, the configured fraud tool records browser/device information and mouse-activity indicators from A’s checkout session. The payment details contain B’s cardholder name and billing address. The stock is for C. The billing address does not locate the person operating the browser. A’s session activity and B’s cardholder details come from different sources. Trace whether the system associates the session with A’s user account, B’s card, or both—and whose profile receives any resulting assessment. The name on the card does not establish who performed every recorded action. If B separately completes a banking-app authentication, that is another action to distinguish from A’s checkout activity. Mouse-activity collection is a feature of the fraud tool in this example; it is not a universal 3DS2 authentication field. T5 · T7 . Trace the record to the person or organisation it describes Record Identity to establish What to examine Company registration number, stock quantities and purchasing account The legal company and its order Separate company-only facts from embedded named-user information. Named checkout account and login history The account user and, where established, the person operating it Which account and session references link the activity to that person? Browser/device information and recorded mouse-activity indicators The checkout session and any person linked to that activity Which account or session key connects the observations to A, B or both? Check whose profile receives the output. IP or available device-location information The connection or device context Distinguish observed or estimated location from the supplied billing address; account for shared networks and location accuracy. Cardholder name, billing address and payment-account details The named cardholder and billing information supplied for the payment The billing address is not proof of the checkout operator’s location. Keep the cardholder and operator separate unless their identity is established. Authentication result and subsequent risk or profile labels The transaction, authentication participant and subject of each assessment Which input and identifier produced the result, and to whose record was it attached? 3DS2 examines the transaction and its context. EMV 3DS exchanges transaction, payment-method and device information to support authentication. Risk assessment can include device or IP-related context, and a challenge can involve the cardholder’s banking app. The exact fields and flow depend on the implementation. T6 · T7 . That gives a concrete route to investigate: checkout user → session and device → payment account → authentication result → any later assessment. A successful authentication does not, by itself, establish who physically operated every device or their precise location. Ask how the systems linked these roles and whether a later profile merged them incorrectly. A PRECISE FOLLOW-UP “The purchase was for a business and the checkout user was different from the named cardholder. My request concerns the personal information relating to my activity. Please distinguish browser/session observations, any mouse-activity indicators, cardholder and billing details, and authentication records. Which references linked those records, and whose profile received each resulting assessment? Please explain any attribution of my activity to the cardholder, any use of the billing address as my location, and any classification of my identifiable activity as company-only information.” This is an anonymous teaching example. Information can relate to more than one person; the response must address the requester’s personal information and the rights of others. Company-only information and any applicable access exemption require their own assessment. L1 · L7 .", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#responsibility-loop", "heading": "One checkout. A traceable set of responsibilities.", "text": "COMMON REPLY 02 / “ASK THE OTHER PROVIDER” One checkout. A traceable set of responsibilities. A customer experiences one purchase. Behind it, the merchant, payment service and issuer may exchange several messages and retain different records. Shared fields or linked references can connect those records without every participant receiving one identical payload. T6 . The role follows the processing activity. “Payment processor” is a commercial description, not a complete GDPR role analysis. The same service can process some information on a merchant’s instructions and act as a controller for a separate purpose. Receiving the same fields does not automatically make two organisations joint controllers. L10 · L11 . Illustrative responsibility map · establish the real arrangement for each operation Processing operation Who determines it in this example? What a useful response addresses Customer account and order administration The merchant decides the purpose; it is the controller for that operation. The personal order/account records it controls, including records held on its behalf. A payment service acting only on documented instructions The merchant is controller; the service acts as its processor for this operation. The controller handles the SAR with the processor’s assistance. A service’s separately determined security processing The service determines that separate purpose and acts as controller for it. The service addresses the relevant personal information it controls, subject to applicable limits. Jointly determined processing, if established Two parties jointly determine the relevant purposes and means. Their arrangement must not prevent the person exercising rights against either controller. These are assumed roles for explanation. The ICO explains both operation-specific roles and responsibility for SAR responses. L10 · L1 . Follow the reference through the hand-off Ask which order, payment, authentication or customer references connect your records; what each party received or derived; and which purposes it controls. A referral can help locate another controller. It does not resolve the referring organisation’s own processing merely because another party also holds information. A PRECISE FOLLOW-UP “Please distinguish the processing you undertake as controller from processing performed on another controller’s instructions. Address the personal information for which you are responsible, including records held on your behalf. Where you refer part of my request elsewhere, please identify the relevant controller and explain which processing that referral covers. Please provide the applicable source and recipient information for my records.” The useful challenge is to an unexplained gap in responsibility. It does not require proving that every party received identical bytes, nor asking one party to produce records it does not hold or control.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#policy-to-records", "heading": "“I have read the policy. Please answer the request.”", "text": "A PRACTICAL FOLLOW-UP / UK DATA PROTECTION “I have read the policy. Please answer the request.” A privacy notice and a copy of your personal information answer different questions. A policy link can supply relevant supplementary information. It does not replace the personal data requested under Article 15. That can include observed activity and inferred attributes where they are personal information held about you. L1 · L2 . Notice obligations and access rights Provision What it addresses Useful question Article 13 Privacy information when personal data is collected from the person, including through observation. What are you collecting from my activity, and for which purposes? Article 14 Privacy information when personal data is obtained from another source, subject to applicable exceptions. Which other sources supplied information about me? Article 15 Confirmation of processing, access to the person’s personal data and supplementary information. What data and derived records do you actually hold about me? L6 · ICO notice guidance · L1 · ICO access guidance . The right belongs to an individual. Information arising from a business relationship can still relate to an identifiable person; company records are not automatically that person’s personal data. Why 3DS2 makes the question concrete EMV 3DS exchanges transaction, payment-method and device information for authentication. A receipt or account profile may not show all personal records created around that process. Article 15 applies independently of 3DS2. It was not created by the protocol. T6 · EMVCo Keep the collection systems distinct Authentication messages, advanced fraud signals, merchant analytics and CRM imports are separate systems. The protocol does not mandate every tracking field mentioned in research, nor establish universal marketing access or tracking of every non-buying visitor. T5 · Collection distinctions Ask about the actual personal records Include relevant identifiers, assessments, derived labels and records held on the controller’s behalf. A controller’s response should address the request across the processing for which it is responsible, including help from its processors. L1 · Controller responsibilities A follow-up you can adapt Request text · select and copy, or download Thank you. I have read your privacy policy. My request concerns the personal information you actually process about me, including relevant payment, authentication, fraud-assessment, reward and customer-profile records.\n\nPlease provide the personal information you hold, including observed activity, identifiers and inferred scores, labels or segments where these relate to me, together with the applicable information about purposes, sources where not obtained directly from me, recipients and retention.\n\nPlease include relevant personal information held on your behalf by processors, and explain unfamiliar codes or classifications so I can understand the disclosure. Where relevant personal records show copying, exports, matching or subsequent use, please include them within your response.\n\nA policy link may explain your general practices, but please also address the requested personal records. If you withhold information or rely on an exemption, please explain your position to the extent the law permits. Please distinguish information you do not hold from information you hold but are withholding. Copy follow-up Download text Nothing is sent from this page. Access has a defined scope. This requests personal information, not automatic disclosure of every source-code file, contract, security rule or other person’s data. Applicable exemptions require assessment. “Fraud prevention” is not a blanket answer: the crime-related exemption depends on the prejudice that disclosure would be likely to cause. L7 . Separate the personal-data request from the technical enquiry For an SME reviewing its suppliers, also ask which integrations are enabled, which fields each can read or export, how permissions are scoped, and whether source and purpose survive transformations. Request the relevant configuration history, data dictionary, retention rules and audit evidence through the appropriate contractual or review route. Those records can help test the explanation; Article 15 does not guarantee delivery of every underlying document. Primary sources and scope · checked 15 October 2026 The anonymous examples build on themes in FilmPass’s research. Current documentation supports the mechanisms below. For an earlier period, check the documentation and configuration applicable at that time. T1 · Merchant-visible risk results. Stripe: transaction risk prevention . Documents risk outcomes and conditional availability of scores; it does not establish access to every input. T2 · Reports and exports. Stripe Sigma: included capabilities and Radar analytics . Documents CSV downloads and fraud reporting. Verify the actual export schema and account entitlement. T3 · Field transformation and destinations. Twilio Segment: destination insert functions . Documents transformation, enrichment and filtering before supported downstream destinations. T4 · Identifiers and customer attributes. Twilio Segment: Identify specification . Shows user identifiers and traits used in configured integrations. T5 · Raw signals and stated restrictions. Stripe: advanced fraud detection . Describes its advanced risk-factor data as restricted to fraud detection and security, with no advertising use. Distinguishes this collection from basic 3DS2 device information. These stated limits are retained, not treated as proof of a hidden raw-data export. T6 · Authentication data. EMVCo: EMV 3-D Secure . Explains the transaction, payment and device information used for authentication. T7 · Device context and separate authentication. EMVCo: supporting the deployment of EMV 3-D Secure . Describes device and IP-related context, and authentication through a banking app separately from the checkout device. The three-role stock-purchase example is an illustrative application of those distinctions. L1 · Access and responsibility. ICO: what is the right of access? . Explains the copy and supplementary information, including recipient information, and controllers’ responsibilities for records held by processors. L2 · Observed and inferred information. ICO: supplying information to the requester . Covers access scope and making a disclosure understandable. L3 · Making data accessible. ICO: data sharing covered by the code . Distinguishes controller sharing, processor arrangements and internal movement. L4 · Subsequent purposes. ICO: purpose limitation . Current guidance on compatibility, lawful basis and further use. L5 · Tokens and identifiability. ICO: pseudonymisation . Explains the significance of additional identifying information and the recipient’s position. L6 · Privacy information. ICO: when to provide privacy information . Distinguishes collecting from a person and obtaining data from other sources. L7 · Limits on access. ICO: relevant SAR exemptions . Explains case-specific assessment and the crime-prevention prejudice test. L8 · The personal-data test. ICO: what is personal data? . Distinguishes information about legal companies and identifiable individuals. L9 · Business contacts. ICO: business-to-business marketing . Confirms that a business context does not automatically remove personal information from UK GDPR protection. L10 · Roles by activity. ICO: determining controller and processor roles . Explains different roles for different processing purposes. L11 · Who determines purposes and means? ICO: controllers and processors . Defines the roles; shared data alone does not settle them. Data-law update: follow the purpose and the actual use → Legislative context checked 21 October 2026.", "sources": [ "https://docs.stripe.com/radar/transaction-risk-prevention", "https://stripe.com/sigma/pricing", "https://docs.stripe.com/radar/analytics", "https://www.twilio.com/docs/segment/connections/functions/insert-functions", "https://www.twilio.com/docs/segment/connections/spec/identify", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://www.emvco.com/emv-technologies/3-d-secure/", "https://www.emvco.com/knowledge-hub/supporting-the-deployment-of-emv-3-d-secure-solutions/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/what-is-the-right-of-access/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/how-can-we-supply-information-to-the-requester/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/data-sharing-covered-by-the-code/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/purpose-limitation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/the-right-to-be-informed/when-should-we-provide-privacy-information/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/what-exemptions-are-relevant-for-sars/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-is-personal-data/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/business-to-business-marketing/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/how-do-you-determine-whether-you-are-a-controller-or-processor/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/technical-questions.html#follow-the-referral", "heading": "When each provider points to the other.", "text": "When each provider points to the other. Ask each organisation to identify its own role, the records it holds and which part of the explanation belongs elsewhere. Then reconcile the answers against the same order and payment references. Explore the merchant, platform and processor example →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html", "title": "Connections & customer knowledge", "sections": [ { "id": "https://filmpass.nsstudio.uk/diagrams.html#section-1", "heading": "Connections. Context. Customer knowledge.", "text": "04 / CONNECTIONS Connections. Context. Customer knowledge. 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. Reading guide ↗ Follow the supporting record. Follow the supporting record. ORGANISATION → DOCUMENT → ROLE → SOURCE REFERENCE. Every documented connection needs its own supporting source. ORGANISATION DOCUMENT ROLE SOURCE REFERENCE Every documented connection needs its own supporting source. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Follow the supporting record. ORGANISATION → DOCUMENT → ROLE → SOURCE REFERENCE. Every documented connection needs its own supporting source. ORGANISATION DOCUMENT ROLE SOURCE REFERENCE" ] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#diagram-purpose", "heading": "Connections & customer knowledge", "text": "How to read this explanation. The technical explanation describes how records can be linked and reused when the stated access, identifiers and integrations are present. The names, amounts and sample records are invented to demonstrate the mechanism. The examples do not reproduce private case records. Provider-specific field availability and each assumed step are identified separately.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#payment-profile-example", "heading": "How transaction data can build a profile.", "text": "INTERACTIVE SANKEY · PAYMENT DATA & CRM CONTEXT How transaction data can build a profile. 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. Records linked to a CRM profile 70 of 100 What enrichment adds. 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. Why the purpose matters. 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 →", "sources": [ "https://docs.stripe.com/metadata" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#sme-two-stage-example", "heading": "The SME pays for stock. Who gains the customer knowledge?", "text": "INTERACTIVE EXAMPLE · THE SME’S TWO-SIDED EXPOSURE The SME pays for stock. Who gains the customer knowledge? 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. Illustrative inputs: an SME buys 100 ticket codes for £600, sells 40 to its customers and remains their point of contact. The supplier already has the SME account and stock-order history. The controls below change whether downstream events can be connected to that account and to identifiable customers. Change the information available downstream Ticket or batch reference links a later purchase or redemption to the SME’s stock order. A downstream system receives an identifiable customer reference and has a matching lookup. The operator uses linked records for its own commercial profiling or targeting. These switches describe the information available and the commercial use assumed in this illustrative scenario. Reset the example 1 · SUPPLIER → SME STOCK SME purchase profile 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. 2 · SME → ITS CUSTOMERS The SME builds the relationship 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. 3 · DOWNSTREAM EVENTS → CRM Customer linkage The commercial exposure 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. Who answers for each use of the data? 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. Which records trace this path? 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. Explore identifier matching → ICO · responsibility for own-purpose processing ↗", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#fraud-inputs-and-derived-records", "heading": "How can fraud-related information become a marketing input?", "text": "How can fraud-related information become a marketing input? 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. The whole chain is the unit of analysis. 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 that can contribute to a fraud assessment; availability depends on the integration. 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? The output can carry information beyond the original check. 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. One worked example. Five traceable steps. 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. Observe: payment record order_104 has an outcome requiring review. Match: the order table connects order_104 to customer_27 . Combine: purchase history and the review outcome become inputs to a custom segmentation rule. Translate: the rule creates offer_group = restricted . Act: a campaign excludes 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. Four ways information can carry forward. Trace the accessible information, the join and the resulting use. 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. Read the statement and follow what it leaves unanswered. “Fraud prevention is not a marketing tool.” This addresses the tool’s function. It leaves a different question: does a result from that tool become an input to marketing elsewhere? “We do not share the data.” 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. A concrete documentation comparison: Stripe. 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? Sources, field scope and dates Device/activity collection and stated use restrictions Fraud-related reporting fields and warehouse analysis EMV 3DS authentication ICO: purpose limitation 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.", "sources": [ "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://stripe.com/guides/improve-fraud-management-with-radar-and-stripe-data", "https://www.emvco.com/emv-technologies/3-d-secure/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/purpose-limitation/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#capture-to-crm", "heading": "From ticket purchase to a linked profile.", "text": "From ticket purchase to a linked profile. 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. Same infrastructure. Compare the use. Payment-risk use Marketing misuse Payment-risk use Risk results are joined to order records to investigate payments. In this view, the later CRM and campaign steps use order information; the risk result stays within the payment investigation. Switch views: the systems stay in place. What changes is the information carried onward and the decision made from it. Marketing misuse: the purpose changes inside the connection. Example setup: the team can read a payment review result, match the order to a customer, transform fields in a warehouse and write to the CRM. Here it repurposes that result for an unrelated campaign without assessing or explaining the new use. Read the output: a report, API or export supplies the review result and order reference. Join the context: the order reference connects it to customer history; invoice, review or redemption records contribute additional attributes. Create a new field: a rule turns the combined inputs into an “exclude from promotion” label. Use it commercially: the CRM stores that label and a campaign applies it to the customer. The consequence: a fraud-related result influences marketing while the original telemetry remains in the fraud system. Renaming it does not erase the source or change the fact of reuse. Inspect the join and the rule: those records explain the transition that separate product descriptions leave unanswered. An illustrative ticket-commerce data architecture A worked example connects two storefronts, a shared checkout, invoice records, a payment processor and its fraud system, reporting, a warehouse and a CRM. Review, redemption and enrichment records add context through matching references. The toggle changes the downstream fields: order information in the payment-risk view; an additional risk-derived customer label in the marketing-misuse view. Original fraud telemetry remains in the fraud system. Buyer / benefit member Order and supplied details Supplier A storefront Separate seller and order records Supplier B storefront Separate seller and order records Platform / checkout integration Shared platform assumed in this example Invoice plugin Order, billing and invoice references Payment processor Account, payment and available results Restricted fraud system Internal telemetry and risk processing Reporting / export / connector Available risk fields, API data and events Ticket / redemption system Optional code-use events SQL warehouse / matching Joined tables; chosen hosting region External enrichment provider Demographic segments / estimates Review / feedback platform Rating, text, reference if available CRM / customer records Selected joined fields and provenance Marketing / messaging integration Segments, audiences and campaign rules Available risk fields / results Internal inputs → accessible results Order fields → customer record Risk-derived label → customer record Profile field → commercial action The lines show information routes. In the payment-risk view, downstream CRM fields come from orders. In the misuse view, the orange route also carries a risk-derived attribute. Storefronts can be hosted e-commerce platforms or custom builds: their order and customer references supply the matching keys. 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. 1. Capture and create 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. 2. Connect and enrich 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. 3. Use and account for it 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. Why connecting existing tools can be commercially attractive. 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 → Where to start examining the route. Export configuration and logs: identify fields, dates, requesting accounts and destinations. Warehouse queries and lineage: identify join keys, source tables, renamed fields and derived attributes. CRM mappings and segment rules: establish which attributes were imported and which actions or decisions used them. Purpose and responsibility records: compare the stated collection purpose with each later use, the entities making decisions, permissions, retention and any relevant assessments. Regional access and replication records: identify receiving entities, storage locations, replicas, exports and access locations. 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. Reviews add another kind of context. 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. Where can the SQL warehouse route information? 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. Illustrative regional routing and remote access A primary SQL warehouse in a chosen UK or EEA region can, if configured, replicate selected tables into another cloud region. Separately, an authorised analyst or integration in another location can query the primary service. Replication, remote access and downstream export are distinct routes to establish. Primary SQL warehouse Chosen UK / EEA region — example Selected replica / shared dataset Another region / cloud, if configured Configured replication Authorised analyst / integration Other location: query results or downstream export Results to authorised remote user Optional routes, not automatic global distribution. Check regions, roles, logs and receiving entities. 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. An overseas address is not a data-flow map. A listed location may represent an operational office, subsidiary, shared workspace or virtual office. Its address alone does not establish where information is stored, processed or accessed. Ask what each location does: which legal entity operates there, whether it handles customer information, and how that relates to hosting regions, replicas and remote access. Fraud-related information can leave the payment system. 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? Five records that expose the combined use. Field inventory: collected inputs, accessible results and separately collected plugin events. Join map: order, customer, invoice and other references that connect the records, including any cross-supplier mapping. Transformation rules: calculations, labels and inferences created from the joined information. Destination and action: CRM fields, campaign rules, recipients and automated decisions that use the result. Purpose record: how the combined use was explained and justified, including the use of benefit-membership or employment context. 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? → Public documentation for the individual building blocks 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. Reporting and warehouse access to fraud-related fields Authentication data categories and conditional fields Review API fields and authenticated access Configured cross-region and cross-cloud replication Sharing across regions and cloud platforms Invoice creation from storefront orders CRM-to-destination connector and field access Marketing-platform profile fields Published demographic-enrichment example Platform and connected-account events Processor fraud-data collection and published use limits 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.", "sources": [ "https://stripe.com/guides/improve-fraud-management-with-radar-and-stripe-data", "https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/improving-risk-emv-3-d-secure-whitepaper-v2-analysis-and-frictionless-flow/technical-features/", "https://developers.trustpilot.com/service-reviews-api", "https://docs.snowflake.com/en/user-guide/account-replication-intro", "https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-platforms", "https://sufio.com/articles/shopify/create-documents-orders/create-invoices/", "https://fivetran.com/docs/connectors/applications/salesforce", "https://support.iterable.com/hc/en-us/articles/206430145-Managing-User-Profile-Fields-in-Iterable", "https://www.caci.co.uk/insights/how-marie-curie-use-data-insights-to-improve-supporter-engagement-increase-income/", "https://docs.stripe.com/connect/webhooks", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "An illustrative ticket-commerce data architecture A worked example connects two storefronts, a shared checkout, invoice records, a payment processor and its fraud system, reporting, a warehouse and a CRM. Review, redemption and enrichment records add context through matching references. The toggle changes the downstream fields: order information in the payment-risk view; an additional risk-derived customer label in the marketing-misuse view. Original fraud telemetry remains in the fraud system. Buyer / benefit member Order and supplied details Supplier A storefront Separate seller and order records Supplier B storefront Separate seller and order records Platform / checkout integration Shared platform assumed in this example Invoice plugin Order, billing and invoice references Payment processor Account, payment and available results Restricted fraud system Internal telemetry and risk processing Reporting / export / connector Available risk fields, API data and events Ticket / redemption system Optional code-use events SQL warehouse / matching Joined tables; chosen hosting region External enrichment provider Demographic segments / estimates Review / feedback platform Rating, text, reference if available CRM / customer records Selected joined fields and provenance Marketing / messaging integration Segments, audiences and campaign rules Available risk fields / results Internal inputs → accessible results Order fields → customer record Risk-derived label → customer record Profile field → commercial action", "Illustrative regional routing and remote access A primary SQL warehouse in a chosen UK or EEA region can, if configured, replicate selected tables into another cloud region. Separately, an authorised analyst or integration in another location can query the primary service. Replication, remote access and downstream export are distinct routes to establish. Primary SQL warehouse Chosen UK / EEA region — example Selected replica / shared dataset Another region / cloud, if configured Configured replication Authorised analyst / integration Other location: query results or downstream export Results to authorised remote user Optional routes, not automatic global distribution. Check regions, roles, logs and receiving entities." ] }, { "id": "https://filmpass.nsstudio.uk/diagrams.html#sme-business-map", "heading": "Can transaction records reveal an SME’s business model?", "text": "Can transaction records reveal an SME’s business model? 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 Separate records → a relationship graph Separate records Join the available records Invented records: quantities come from order/invoice data, not an assumed payment field. Day Recorded relationship Units Source assumed available 1 Supplier A → SME 100 Purchase order/invoice 4 Supplier B → SME 50 Purchase order/invoice 8 Supplier A → SME 100 Purchase order/invoice 5 SME → Benefit channel X 80 Resale order record 9 SME → Benefit channel Y 40 Resale order record An invented SME supplier and sales-channel graph Separate supplier, SME and benefit-channel records. The joined view assumes a party can access all five invented rows and match the SME and product references. It reveals two suppliers, repeat purchasing and two resale channels. Supplier A Supplier B The SME Benefit channel X Benefit channel Y Each record describes one event. Separate records show individual purchases and sales. The joined view assumes a team can read these five rows and match the SME and product references. Switch views to see the relationship information that the join creates. The join creates a business picture. The graph now shows two suppliers, two resale channels, 250 purchased units and 120 resold units . It also exposes two purchases from Supplier A seven days apart. The relationship map emerges from records originally created for separate transactions. Across a longer history, an analyst can estimate supplier dependence, replenishment timing and channel demand. Keep observed totals separate from predictions, and record how much of the business the source data covers. Which participant can see the graph? 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. Where the potential competitive harm begins. 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 → Research sources and assumptions 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. SQL reporting and available transaction data Platform/connected-account charge arrangements CMA research on algorithmic competition risks 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.", "sources": [ "https://docs.stripe.com/data/sigma", "https://docs.stripe.com/connect/charges", "https://www.gov.uk/government/publications/algorithms-how-they-can-reduce-competition-and-harm-consumers/algorithms-how-they-can-reduce-competition-and-harm-consumers" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "An invented SME supplier and sales-channel graph Separate supplier, SME and benefit-channel records. The joined view assumes a party can access all five invented rows and match the SME and product references. It reveals two suppliers, repeat purchasing and two resale channels. Supplier A Supplier B The SME Benefit channel X Benefit channel Y" ] } ] }, { "id": "https://filmpass.nsstudio.uk/jurisdiction.html", "title": "Roles & responsibility", "sections": [ { "id": "https://filmpass.nsstudio.uk/jurisdiction.html#section-1", "heading": "Responsibility across borders.", "text": "06 / RESPONSIBILITY Responsibility across borders. How to identify the organisations responsible for processing, the relevant jurisdictions and the evidence needed to trace an incident. Illustrative mechanism ↗ Follow the processing role. Follow the processing role. PROCESSING EVENT → CONTROLLER → PROCESSOR → RESPONSIBILITY. Identify who decides the purpose and who acts on instructions. PROCESSING EVENT CONTROLLER PROCESSOR RESPONSIBILITY Identify who decides the purpose and who acts on instructions. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Follow the processing role. PROCESSING EVENT → CONTROLLER → PROCESSOR → RESPONSIBILITY. Identify who decides the purpose and who acts on instructions. PROCESSING EVENT CONTROLLER PROCESSOR RESPONSIBILITY" ] }, { "id": "https://filmpass.nsstudio.uk/jurisdiction.html#section-2", "heading": "Who decides the purpose?", "text": "Explore the fictional cross-border example → Multiple entities or countries can make an account difficult to follow. They do not, by themselves, establish a legal loophole or an exemption. Use the guidance applicable to the activity and date you are examining. 01 Who decides the purpose? Identify the controller for the specific processing operation. A company can have different roles for different operations. Obtain the applicable contract, notice and actual instructions. 02 Who acts on instructions? A processor acts on a controller’s behalf. Trace the subcontracting chain, instructions, forwarding and assistance with rights requests; do not infer every role from a product label. 03 Where is information accessible? Map the sending and receiving organisations and locations. Assess whether the UK restricted-transfer rules apply and, where they do, the relevant transfer mechanism and safeguards. 04 What is the unresolved question? Record the request, recipient, receipt, scope, response, extension and missing information. Separate data-protection issues from payment disputes, commercial claims and court procedure. An example responsibility map Retail service Purpose & member relationship Evidence: notice, terms, controller decision and service records. Service provider Processing & instructions Evidence: agreement, role for each activity, subprocessor list and response chain. Overseas recipient Access & transfer safeguards Evidence: location, recipient identity, transfer assessment and applicable mechanism. Official guidance Official sources checked 6 October 2026. Current documentation may differ from historic versions. ICO: controllers and processors ↗ Roles depend on decisions and instructions for the processing operation. ICO: who the UK GDPR applies to ↗ Scope can extend beyond organisations based in the UK. ICO: international transfers ↗ Assess the particular transfer and applicable safeguards. The ICO flags that some guidance is under review following the Data (Use and Access) Act. Apply the rules and guidance relevant to the event date.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/who-does-the-uk-gdpr-apply-to/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/jurisdiction.html#invoice-trail", "heading": "Follow the invoice. Follow the data separately.", "text": "ILLUSTRATIVE ACCOUNTING EXAMPLE Follow the invoice. Follow the data separately. International billing and accounting between subsidiaries can make a transaction harder to trace from a summary alone. Currency conversion, fees, net settlement and group-level totals may separate the visible amount from the original customer event. These scenarios explain accounting routes and the records needed to reconstruct them. Show supporting transaction references Customer-facing service Example invoice INV-014 £20 billed by Entity A. Local reference: order_demo_014 → charge_demo_014. International billing service Example settlement SET-08 Net or converted settlement needs its own reconciliation. Supporting ledger: source charge, fees, exchange rate, transfer and payout references. Group accounts Example journal IC-22 A group total summarises the underlying events; customer-event records provide the detailed trail. Supporting schedule: both legal entities, invoice reference, journal counterpart and reconciliation. Summary view: the records shown are insufficient to reconcile the £20 customer event across the chain. All references and entities are invented. The switch reveals the categories of supporting evidence used to trace an accounting route. The money trail Match the seller’s legal entity and registration number to invoice, charge, transfer, payout, ledger entry and intercompany schedule. Keep original and converted amounts, fees and dates. The information trail Separately match source field, export, receiving organisation, identifier mapping, purpose and receiving-system log. Follow the invoice description, legal entity, payment route and records of information received by each organisation. Record any missing part of that trail. Stripe: transaction, balance and payout reconciliation fields ↗ · Explore identifier matching →", "sources": [ "https://docs.stripe.com/data/query-transactions" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/jurisdiction.html#section-4", "heading": "Different roles still require specific answers.", "text": "Different roles still require specific answers. A provider can be a processor for one activity and a controller for another. Assess the decisions made by each organisation for each processing purpose. The useful comparison is purpose by purpose: who decided what to collect, who received it, what they did with it and who can provide the records? If each organisation points to the other without addressing its own processing, that leaves a concrete gap to document. A general policy or a tokenised card number does not answer whether a separate identifier was retained or reused. International invoices, central finance teams and intercompany accounting can make reconciliation harder. Trace the accounting entries and the data-access and transfer records alongside one another. See the evidence needed to connect the steps →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/jurisdiction.html#layered-payment-responsibility", "heading": "One purchase. Several responsibilities.", "text": "One purchase. Several responsibilities. MERCHANT · PLATFORM · PAYMENT PROCESSOR See the full capture-to-CRM diagram → “Ask the merchant” and “ask the processor” can each describe only part of the answer. The customer needs the route explained across the organisations that operated it. Consider an invented example: Supplier A and Supplier B sell cinema tickets through separate storefronts. Both use a platform that integrates a payment processor. The platform role might belong to one supplier or to another company; the role and legal entity must be established, not guessed from a website name. Separate brands, separate companies and shared infrastructure are different facts. Part of the route What needs explaining? Records to ask about Each supplier What did it sell, collect and instruct its systems to do? Order, invoice, checkout configuration, notices and instructions. Platform operator Which accounts did it connect and which events could its integration receive? Account mapping, permissions, event subscriptions and delivery logs. Payment processor Where was the charge created and how were processing, authentication and risk decisions handled? Transaction references, charge type, relevant account context and available decision records. Any later data recipient What arrived, what was joined to it and what was the new purpose? Received fields, matching rules, access logs, retention and the basis for that use. What Connect makes technically possible. Stripe Connect is a documented example of platform payment infrastructure. With direct charges, the charge is created on a connected account. With destination charges, a platform charge sends funds to a connected account. Separate charges and transfers allow a platform to create a charge and transfer funds separately, including to multiple connected accounts. These choices affect payment records, displayed business information and which account is debited for refunds or disputes. Connect webhooks can notify a configured platform endpoint of activity on connected accounts. That provides a concrete reason to ask about the platform’s information access as well as each merchant’s. Event scope, account configuration and permissions matter. Using the same processor does not establish that two merchants share a Connect platform, a CRM, or each other’s information. Follow the information separately from the money. A payment route is not a map of every later data use. Distinguish the merchant’s own order data, payment results available to an integration, and the processor’s internal fraud telemetry. Connect or a reporting tool is not evidence that raw fraud telemetry was exportable. Stripe’s published description says its advanced fraud-detection risk factors are used for fraud detection and security, not advertising. A claim about another use needs evidence identifying the field, recipient, access route and subsequent processing. The useful challenge: if an answer says “we do not share fraud data”, ask which category it means and whether the explanation also covers accessible results, derived classifications and separately collected merchant data. Access, receipt, matching and use are distinct steps to establish. Questions that connect the answers. Which legal entity sold the ticket, operated the platform and held the relevant payment account? Which charge type and account identifiers connect the order, payment and any transfer? Which party configured the risk rule, received the result or chose the next action? Which fields reached a webhook, report, export or CRM, and what records establish receipt and later use? If a result was reused or combined with other records, who determined that purpose, what justified it, and how could a person challenge an inaccurate inference? Which part can each organisation answer, and who will coordinate the remaining explanation? Purpose limitation, a valid lawful basis, transparency, minimisation, accuracy, access controls and appropriate retention remain important when personal information is enriched or reused. Fraud prevention is not a blanket permission for unrelated commercial use. Where processing is likely to create a high risk, a data protection impact assessment is required. The lawful route depends on the actual processing; neither universal consent requirements nor automatic permission should be assumed. For two suppliers and their processor, it can therefore be necessary to examine all three contributions together. Each organisation’s acts, purposes and decisions still need to be identified. The roles and records supply the explanation—not the repeated referral. Illustrative example. Current documentation checked 31 October 2026; use the configuration and rules applicable to the event being examined. Stripe: Connect charge types · Stripe: Connect webhooks · Stripe: advanced fraud detection · ICO: sharing information for fraud prevention", "sources": [ "https://docs.stripe.com/connect/charges", "https://docs.stripe.com/connect/webhooks", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/transparency.html", "title": "Consumer & SME transparency", "sections": [ { "id": "https://filmpass.nsstudio.uk/transparency.html#section-1", "heading": "Protection people can trust. Questions SMEs can ask.", "text": "08 / FRAUD PREVENTION & TRANSPARENCY Protection people can trust. Questions SMEs can ask. Fraud controls protect customers and businesses. Understanding their effects, the information available to each participant and the routes to challenge errors is part of making those systems accountable. Reading guide ↗ A purpose needs an explanation. A purpose needs an explanation. STATED PURPOSE → ACTUAL USE → LAWFUL BASIS → RECORDS TO EXAMINE. Follow the purpose, the recipients and the evidence of each use. STATED PURPOSE ACTUAL USE LAWFUL BASIS RECORDS TO EXAMINE Follow the purpose, the recipients and the evidence of each use. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "A purpose needs an explanation. STATED PURPOSE → ACTUAL USE → LAWFUL BASIS → RECORDS TO EXAMINE. Follow the purpose, the recipients and the evidence of each use. STATED PURPOSE ACTUAL USE LAWFUL BASIS RECORDS TO EXAMINE" ] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#technical-update", "heading": "Turn a policy reply into a precise question", "text": "TECHNICAL QUESTIONS Turn a policy reply into a precise question Follow the fields, then use the Article 15 follow-up to ask for the personal records actually held. Explore the examples 20 questions: follow the flow Article 15 follow-up", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#section-3", "heading": "Preventing harm.", "text": "Legitimate protection Preventing harm. Data protection law can enable responsible information sharing to prevent scams and fraud. A valid lawful basis, proportionate sharing and appropriate safeguards still matter. ICO fraud-prevention guidance ↗ Potential SME risks Understanding the impact. Errors, unclear decisions or unequal access to useful information could disadvantage a small business. The cause and competitive effect must be investigated, rather than assumed. Explore the research questions ↓ Transparency Knowing who does what. People should receive understandable information about who uses their personal data and why. A clear route to the responsible organisation helps them exercise their rights. ICO fairness and transparency guidance ↗ This section presents general research questions and proposals. It does not conclude that a provider, merchant or membership scheme engaged in anti-competitive conduct. A business losing sales, a data-protection concern and harm to competition are different questions.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/lawfulness-fairness-and-transparency/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#risk-questions", "heading": "Where could an SME face a disadvantage?", "text": "COMPETITION / QUESTIONS TO TEST Where could an SME face a disadvantage? The CMA’s 2021 research identifies ways algorithmic systems can benefit markets and ways they may harm consumers or exclude competitors, including self-preferencing. This research provides the published context for the questions below. Read the CMA research · published 19 January 2021 ↗ Potential mechanism Why it could matter Evidence needed to assess it Incorrect or unexplained flags A legitimate customer or transaction could encounter friction; an SME may struggle to explain or correct it. Decision and review logs, false-positive measurements, the reason for the action, correction records and alternative causes. Unequal information access One participant could have commercially useful insight that another cannot evaluate or contest. The exact fields, permitted recipients, access dates, use of the information and measurable effect. Access or eligibility restrictions Admission rules could limit which businesses or customers can participate. Published criteria, comparable applications, contracts, consistent treatment and any security or commercial justification. Dependence on an intermediary Unclear responsibilities or limited alternatives could make resolving problems or changing provider difficult. Available alternatives, switching constraints, contracts, costs and the intermediary’s position in the relevant market. A change of purpose Using selected information for marketing, segmentation or another purpose raises a separate question from collecting it for security. Actual exports, recipients, field mappings, destination records, stated purposes and applicable authority. Questions for examination include the market, conduct, effects, underlying records and relevant legal framework.", "sources": [ "https://www.gov.uk/government/publications/algorithms-how-they-can-reduce-competition-and-harm-consumers/algorithms-how-they-can-reduce-competition-and-harm-consumers" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#closed-groups", "heading": "Membership should make the relationship clearer.", "text": "CLOSED USER GROUPS Membership should make the relationship clearer. Here, “closed user group” means an offer limited by eligibility—for example, employees, association members or another defined audience. Our proposal is to make the service and data relationships within membership offers easier for members and participating SMEs to understand. 01 Eligibility and access Who qualifies, who sets the criteria, when can access change, and how can a disputed decision be reviewed? 02 The organisation behind each role Who operates membership, sells the voucher, takes payment and fulfils redemption? Which organisation decides each data use? 03 Information and recipients Which identifiers, purchase details, redemption events or risk results are collected? Who receives each category and for what purpose? 04 Matching and later use Are records matched across services? If so, by which identifier and for which purpose? Are security and marketing uses clearly distinguished? 05 Correction and challenge Where can a person raise an error, request an explanation or seek review? How does an SME route a customer’s concern to the right organisation? 06 Changes and accountability Can members find dated terms and privacy notices, relevant retention information and a record of material changes? These are proposed transparency standards, not a claim that every question creates an identical legal disclosure obligation. Useful explanations need not reveal another person’s information, proprietary model code or details that enable fraud. Data-protection rights belong to individuals; a company’s contractual information rights require separate consideration.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#collection-access-use", "heading": "Collection, visibility and reuse are separate steps.", "text": "Collection, visibility and reuse are separate steps. A service may collect information that its business customer cannot see. A merchant may separately hold overlapping order or account information. A reporting tool can only expose the fields and records made available to that account. Ask which exact dataset is involved, who can access it, what export or integration exists, and how the destination uses it. Neither a product name nor a broad statement about sharing answers all four questions. Follow the separate records →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#data-law-update", "heading": "Data-law update", "text": "LEGISLATIVE CONTEXT / CHECKED 21 OCTOBER 2026 Data-law update The Data (Use and Access) Act 2025 changes parts of the UK’s data-protection framework. A lawful basis for necessary fraud prevention does not automatically justify marketing, customer profiling or CRM enrichment. For any further use, examine the actual information, purpose, recipients, applicable lawful basis and purpose-limitation requirements. Consider the rules in force for each relevant event, including any transitional or retrospective provisions. The practical question remains: what happened to the information after collection, and what records explain and justify each use? Data (Use and Access) Act 2025 ↗ · Section 71: purpose limitation ↗ · ICO: recognised legitimate interest ↗ · ICO: compatibility and reuse ↗ · GOV.UK: commencement dates ↗ General legislative context. Check the provision, processing event and applicable date together.", "sources": [ "https://www.legislation.gov.uk/ukpga/2025/18/contents", "https://www.legislation.gov.uk/ukpga/2025/18/section/71", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/recognised-legitimate-interest/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/compatibility-and-the-reuse-of-personal-information/", "https://www.gov.uk/guidance/data-use-and-access-act-2025-plans-for-commencement" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#section-8", "heading": "The aim: proportionate protection and meaningful answers.", "text": "The aim: proportionate protection and meaningful answers. FilmPass & Co proposes a clearer account of the service, the data involved and the available routes for correction. That can help members make sense of an incident, SMEs ask focused questions, and reviewers assess the evidence. Sources and status ICO: sharing information to prevent scams and fraud ↗ General guidance on justified and proportionate sharing. ICO: lawfulness, fairness and transparency ↗ General transparency guidance; ICO flags ongoing review following legislative changes. CMA: algorithms and potential competition/consumer harms ↗ CMA research published in 2021. Context checked 6 October 2026. The proposals and risk questions on this page are explicitly distinguished from the source statements.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/lawfulness-fairness-and-transparency/", "https://www.gov.uk/government/publications/algorithms-how-they-can-reduce-competition-and-harm-consumers/algorithms-how-they-can-reduce-competition-and-harm-consumers" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#section-9", "heading": "Make the route challengeable.", "text": "Make the route challengeable. For an SME or consumer, the practical difficulty may be finding which organisation can explain a decision and how to correct an error. The new matching example shows why retained identifiers matter; the accounting example shows why a summary invoice cannot explain the information trail. Explore matching → Follow the record references →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/transparency.html#value-of-linked-data", "heading": "Why linked data is worth asking about.", "text": "VALUE AS WELL AS FLOW Why linked data is worth asking about. Purchase history, verified eligibility and accessible risk information have different uses and access boundaries. Our new guide explains potential commercial value, the evidence needed to establish reuse, and questions to ask about closed user groups. Explore the value of linked data →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/data-value.html", "title": "The value of linked data", "sections": [ { "id": "https://filmpass.nsstudio.uk/data-value.html#commercial-value", "heading": "Value does not require a price tag on a person.", "text": "More useful information can change a decision Value does not require a price tag on a person. 01 Recognise a returning customer Where collection and matching are lawful, linked records can help distinguish repeat visits from new customers and measure the result of an offer. 02 Understand purchase patterns A history of actual purchases can inform audience selection, promotion timing or product recommendations. Tesco Media publicly describes a business based on customer insight and campaign measurement. [1] 03 Reduce losses and unnecessary friction Fraud detection has its own economic value. Stripe describes using device and activity risk factors to distinguish legitimate shoppers from fraudulent purchasers and bots. [3] Explanation is not permission. A useful data combination still needs an appropriate purpose, lawful basis, transparency and safeguards. A security justification does not automatically explain a later marketing use. [4] Tesco’s privacy notice describes coded customer matching, audience creation and aggregated campaign reporting. Those are examples of disclosed commercial uses; they are not evidence that a payment provider’s raw fraud telemetry is available to advertisers. [2]", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#security-boundary", "heading": "Three different things can look similar in a diagram.", "text": "Identify the field before debating the label Three different things can look similar in a diagram. Information What needs establishing The useful question Ordinary purchase and account records Order amount, item category or account identifier. Which merchant collected them, which people they concern and which purposes were explained. Which record entered the CRM, from which source and under whose instructions? Security results visible to a merchant A risk outcome or decision, where a product makes it available. The actual field, account permissions and product configuration at the relevant time. What could this account see or export, and where is the evidence that it did? Raw security telemetry Device or interaction signals held by the provider. Whether the merchant could access those specific fields at all. A reporting tool’s existence does not establish access. Show the schema, field lineage, permissions and sender/recipient logs for the alleged transfer. These are analytical categories, not assertions that all three are exported by any particular service. Stripe’s current documentation states that its advanced fraud-detection risk factors are not used for advertising or provided to advertisers. It also describes activity indicators as scoped to a shopping session on a single site or app. Examine the relevant records to identify which fields are accessible, which routes are configured and how any receiving system uses them. [3] A merchant might also collect similar information independently through its own website or another script. Similar field names or overlapping collection times do not identify which collector supplied a later record.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#worked-value", "heading": "How a small improvement can create value at scale.", "text": "Illustrative arithmetic · not a market valuation How a small improvement can create value at scale. This example models extra contribution from a campaign. It assumes the use is permitted and compares a baseline with an improved response rate. The numbers are invented and are not evidence of any supplier’s revenue. The result is a business outcome under the assumptions shown. It is neither a sale price per profile nor an estimate of any actual damages. People reached × (improved conversion − baseline conversion) × contribution per extra order People reached Contribution per extra order (£) Baseline conversion (%) Improved conversion (%) £250.00 50 additional orders × £5.00 contribution. Incremental contribution before data, campaign and compliance costs. The example does not establish causation in an actual campaign.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#closed-groups", "heading": "Why closed user groups deserve precise questions.", "text": "An eligibility fact can add context Why closed user groups deserve precise questions. In an employee or membership benefit scheme, eligibility may reveal an employer, an occupation or a service affiliation. If that fact is linked to purchase history, the resulting record may be more revealing than an ordinary retail account. What is actually verified, retained or shared depends on the scheme; a discount code alone does not establish a person’s job. A shared CRM or multi-tenant vendor is not, by itself, evidence that two suppliers can see one another’s customers. Examine tenant boundaries, permissions, export destinations and the controller’s instructions. The concern becomes specific when a recipient can access or use information outside the permitted purpose. If identifying and behavioural information is compromised, it can help make a deceptive approach more convincing. NCSC explains how information from breaches can be used in phishing messages and calls. This is a general security risk. [5] Keep the origin attached to the inference. “Eligible member”, “frequent purchaser” and “suspected fraud” are different propositions. If one becomes another downstream, ask for the transformation rule, its source records and any review or correction.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#industry-example", "heading": "What does a secure offer actually secure?", "text": "Read the industry’s own explanation What does a secure offer actually secure? Planit’s June 2025 article describes verified audiences as useful for targeting, retention and customer value. Its security discussion centres on limiting offer leakage and affiliate fraud. That does not establish how member information is protected or reused. [7] Access to an offer Verification asks whether someone qualifies. The separate data questions are who retains the verification, what it reveals, who can join it to purchases and which later uses are permitted. Credit for a purchase The article uses an approximately 85% solo-contribution metric to claim incrementality. Impact defines Solo by the touchpoints in a conversion path. That alone does not identify what would have happened without the offer. [7] [8] Analytical distinction: attribution assigns credit within an observed journey; a causal test estimates the difference made by an intervention. Experimental approaches can compare exposed and control groups. Ask which method supports a particular claim. [9]", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#questions", "heading": "Questions that make the flow reviewable.", "text": "Ask for the explanation and the supporting record Questions that make the flow reviewable. Which exact field is involved: an order record, an inferred category, a merchant-visible risk result or provider-held telemetry? Who collected it, and what links it to the person or transaction in question? Which purpose and lawful basis apply at each stage, including any change of purpose? Which accounts, suppliers or vendors could access it, and what do the access and export logs show? Which decisions used it, and how were its origin, uncertainty and any correction preserved? What measurable business benefit is claimed, and what evidence separates that benefit from coincidence or another cause? Is enriched data automatically unlawful? No. Enrichment describes combining or adding information. Legality depends on the particular collection, purposes, lawful basis, transparency and other applicable requirements. Potential commercial value does not supply legal permission. [4] Does fraud prevention authorise commercial profiling? A fraud-prevention explanation does not, by itself, establish permission for a different marketing purpose. Identify the information actually reused and assess the new purpose and applicable requirements. [4] Does a shared platform prove that records were pooled? No. A common vendor, reporting product or timestamp does not prove a transfer. Look for the actual identifiers, tenant permissions, field mappings and records of the transfer or joint access. Can we put a fixed pound value on every profile? Not from the sources used here. Value depends on the permitted use, accuracy, coverage, freshness, match quality, costs and demonstrated outcomes. The calculator shows transparent assumptions rather than an unsupported price list. Does the failure to prevent fraud offence make every questionable CRM use a crime? No. The Home Office guidance addresses a defined offence involving specified fraud by associated persons intended to benefit a qualifying organisation or its clients, with a reasonable-prevention-procedures defence. It does not establish that every data-protection concern is fraud. [6]", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#sources", "heading": "Sources and the limits of this explanation.", "text": "Primary sources checked 29 October 2026 Sources and the limits of this explanation. Tesco Media / dunnhumby — primary description of customer insight, audience engagement and measurement. A commercial example. Tesco privacy and cookies policy — describes purchase information, coded matching, audience uses and aggregated outputs. Stripe advanced fraud detection — provider explanation of device and activity risk factors and its stated advertising and session-scope restrictions. Documentation is an attributed statement, not an independent audit. ICO guidance on sharing information to prevent scams and fraud — responsibilities, lawful basis and purpose limitation. The ICO marks this guidance as under review following the Data (Use and Access) Act. NCSC data-breach guidance — explains how compromised information can support phishing and deceptive calls. Home Office guidance on failure to prevent fraud — scope of the offence and prevention procedures; in effect from 1 September 2025. Planit, Importance of Closed User Groups — published 26 June 2025, updated 23 July 2025. A marketing agency’s description of CUG benefits, not an audit of data protection. Impact Contribution Report documentation — definition of Solo and other journey metrics. AppsFlyer incrementality experiment documentation — an example of test and held-back control groups. This page explains the value of linked information through educational examples and illustrative calculations.", "sources": [ "https://www.dunnhumby.com/tesco-media/", "https://www.tesco.com/shop/en-GB/zone/privacy-and-cookies-policy", "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/", "https://www.ncsc.gov.uk/guidance/data-breaches", "https://www.gov.uk/government/publications/offence-of-failure-to-prevent-fraud-introduced-by-eccta", "https://www.planit.co.uk/post/importance-of-closed-user-groups", "https://help.impact.com/brand/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-reports/contribution-report", "https://support.appsflyer.com/hc/en-us/articles/360014225577-Run-an-Incrementality-for-remarketing-experiment" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#linked-data-route-value", "heading": "Value comes from the connections.", "text": "Value comes from the connections. A joined profile can be more useful for commercial decisions than its separate source records. Payment outputs, purchases, reviews and redemption events can contribute different attributes. Connectors, a warehouse and a CRM make those attributes available together, reducing the need to build every component from scratch. The critical change is the use: a field created for a security check can become an input to audience selection or offer eligibility. Compare the two views to follow that change through the same tools. Compare the two information routes →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/data-value.html#business-information-value", "heading": "The information advantage: what the join reveals.", "text": "The information advantage: what the join reveals. Joined stock-purchase and resale records reveal relationships, timing and concentration. An analyst can build a supplier-and-channel graph and use a longer history to estimate demand or replenishment. Value comes from the business information created by the join. Where the recipient also has a competing commercial interest, ask which non-public patterns it can see and whether those patterns influence offers, negotiations or approaches to customers. Follow access to the combined tables and the decisions made from them. Compare separate records with a joined business graph →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html", "title": "Reading names & records", "sections": [ { "id": "https://filmpass.nsstudio.uk/record-changes.html#section-1", "heading": "Follow what changed.", "text": "POLICIES & COMPANY RECORDS Follow what changed. A later company name beside an earlier event can make a corporate history difficult to follow. These public examples connect names, company numbers, accounting periods and filing dates so readers can reconstruct who was involved, when and in which role. Reading guide ↗ Names change. Follow the number. Names change. Follow the number. FORMER NAME → CURRENT NAME → SAME COMPANY NUMBER. Compare the event date, filing date and name history. FORMER NAME CURRENT NAME SAME COMPANY NUMBER Compare the event date, filing date and name history. Explore this page →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Names change. Follow the number. FORMER NAME → CURRENT NAME → SAME COMPANY NUMBER. Compare the event date, filing date and name history. FORMER NAME CURRENT NAME SAME COMPANY NUMBER" ] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#questions-from-the-record", "heading": "Their filings. The dates. The questions.", "text": "Their filings. The dates. The questions. Read the entries beside the original forms. Follow the company number through each name, control entry and replacement. Ask for the records that explain the differences. Names and continuity Which name was used at the time? Which later document uses a different name for the same company number? Compare the 2015 and 2024 deeds → Control and timing Why do separate active and ceased entries identify the same continuing company? What happened on the stated effective date? Read the PSC sequence → Original and replacement Which fields changed, why did they change, and which records support the final figures? Compare three share-class filings → Filing-history review: 257 entries across Ello Group Holdings, Ello Group and Spark Marketing Services, back to incorporation. The comparisons below use selected original PDFs; each source is linked beside the relevant observation. Checked 2 November 2026.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#three-name-changes", "heading": "Three name changes. Follow three company numbers.", "text": "Three name changes. Follow three company numbers. Ello Group Holdings, Ello Group and Spark each changed their registered name in 2022. The company number connects the earlier and later names. Companies House name histories and certificate dates Current company / CRN Previous name Name change effective Public records Ello Group Holdings Limited 09685437 The Dining Club Group Limited 5 April 2022 Name history ↗ 2022 filings ↗ Ello Group Limited 09578541 State Bidco Limited 18 February 2022 Name history ↗ 2022 filings ↗ Spark Marketing Services Limited 09975027 Mongoose Promotions Limited 14 February 2022 Name history ↗ 2022 filings ↗ Follow the obligation as well as the name. A change of name leaves the same company's rights and obligations in place. If a later contract, invoice or notice names a different company number, identify the separate entity and the documents governing any transfer of responsibility. A familiar brand name alone cannot answer that question. Companies Act 2006, section 81: effect of a change of name ↗", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/09685437", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history?page=2", "https://find-and-update.company-information.service.gov.uk/company/09578541", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history?page=2", "https://find-and-update.company-information.service.gov.uk/company/09975027", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history?page=2", "https://www.legislation.gov.uk/ukpga/2006/46/section/81" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#accounts-period-and-filing", "heading": "2021 accounts. 2022 names and filing dates.", "text": "2021 accounts. 2022 names and filing dates. All three original accounts covers show the new company name, identify the former name and report a year ended 31 December 2021 . The filing histories record submission in 2022 , after the respective name changes. Read the accounting period, filing date and original cover together Company / CRN Year ended Filing-history date Names on original cover Ello Group Holdings Limited 09685437 31 December 2021 16 May 2022 Ello Group Holdings Limited (was The Dining Club Group Limited) Original accounts, cover page ↗ Ello Group Limited 09578541 31 December 2021 16 May 2022 Ello Group Limited (formerly State Bidco Limited) Original accounts, cover page ↗ Spark Marketing Services Limited 09975027 31 December 2021 9 September 2022 Spark Marketing Services Limited (formerly Mongoose Promotions Limited) Original accounts, cover page ↗ Keep these dates separate: 2021 is the financial period being reported; 2022 is when these accounts were filed. The later name is visible on the original accounts, alongside the former name. The register's current page title and the wording inside an original filing are separate things to check. Another date to compare: Spark's name-change resolution The original name-change filing for company 09975027 contains a resolution stating 11 February 2021 , an NM01 electronic receipt dated 11 February 2022 and a certificate issued on 14 February 2022 . Those are the dates printed in the documents. The certificate date is when the registered name change took effect under section 81. Ask: Was the resolution actually passed on 11 February 2021, as the filed document states? What record explains the interval before electronic receipt on 11 February 2022, and when was the resolution first delivered to Companies House? Original three-page filing: certificate and resolution ↗ Name histories, filing entries and original accounts covers checked 2 November 2026. Public source links remain with Companies House; individual officers' names and signatures are not reproduced here.", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzMzOTM5MTI2MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzOTM5MjE5OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzM1MTM2ODkzOGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzMyOTc3Nzk4N2FkaXF6a2N4/document?format=pdf&download=0" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#company-name-history", "heading": "One company, two displayed entries.", "text": "One company, two displayed entries. What was this company called—and what role did it perform—at the relevant date? Taste Marketing Ltd’s public control register displays these entries: Displayed name Status of entry Notified on Company number Ello Group Limited Active 6 April 2016 09578541 State Bidco Limited Ceased 25 August 2020 6 April 2016 09578541 The matching registration number identifies the same legal company. Its name history lists State Bidco Limited until 18 February 2022. A reader seeing the later name beside a 2016 notification date could mistake it for the name used in 2016. Conversely, the two names could be mistaken for two different companies. The company number and the dated name history are needed to resolve those readings. “Ceased” describes this control entry, rather than dissolution of the company. Compare company numbers, name history and original filings before reconstructing the earlier role. Taste Marketing · control register · Ello Group · name history Public-register example reviewed 31 October 2026. No individual officer details are reproduced.", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/05545626/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09578541" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#state-debtco", "heading": "State Debtco: one company number, two control entries.", "text": "State Debtco: one company number, two control entries. State Debtco Limited’s control register displays Ello Group Holdings Ltd as active and The Dining Club Group as ceased. Both entries identify the same company number, with the leading zero omitted in the older entry. Current PSC display for State Debtco Limited · company 09685583 Displayed controlling entity Registration number displayed Notified / ceased Ello Group Holdings Ltd · active 09685437 Notified 6 April 2016 The Dining Club Group · ceased 9685437 Notified and ceased 6 April 2016 Company 09685437 changed its registered name from The Dining Club Group Limited to Ello Group Holdings Ltd on 5 April 2022 . The company number connects those names. Open the two PSC entries ↗ · Open the name history ↗ Later filings recording an effective date of 6 April 2016 Filing-history date Form and information recorded Original document 18 August 2025 PSC07: cessation of The Dining Club Group, dated 6 April 2016. PSC07 ↗ 18 August 2025 PSC05: changes the nature of control recorded for Ello Group Holdings, dated 6 April 2016. It includes control through a firm that is not a legal person. PSC05 ↗ 18 August 2025 PSC02: notifies Ello Group Holdings, CRN 09685437, as registrable on 6 April 2016, with at least 75% of shares. PSC02 ↗ 20 December 2025 Another PSC05, received electronically on 18 December, records 6 April 2016 again. It sets out at least 75% of shares and voting rights, plus the right to appoint or remove a board majority. December PSC05 ↗ Questions arising from this sequence Why was the same continuing company recorded through a cessation and a new notification, rather than solely a change of name? What control arrangement is each August form intended to record, and how do those forms fit together? What prompted the further December change to the nature of control, still dated 6 April 2016? Which contemporaneous share registers, group records and PSC entries establish the position on that earlier date? Read the complete State Debtco filing sequence ↗", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/09685583/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09685437", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzg0NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzY2N2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNTk1MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ5NTIyMDA0MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#charge-name-comparison", "heading": "A 2015 agreement. A 2024 reference to it.", "text": "A 2015 agreement. A 2024 reference to it. Company 09578541 appears as State Bidco Limited in the original 2015 debenture. The 2024 debenture refers to the earlier agreement using Ello Group Ltd, the name adopted in 2022. Read the actual party lists and definitions together. Company 09578541: names inside the original deeds Document What to find Location Debenture dated 3 August 2015 ↗ Schedule 1 identifies State Bidco Limited, 09578541 . PDF page 31 · printed page 26 Debenture dated 13 November 2024 ↗ The definition of the earlier debenture names Ello Group Ltd as a party to the 3 August 2015 deed. The facilities definition also names it as the original borrower. PDF page 8 · printed page 2 2024 party list Schedule 1 identifies Ello Group Ltd, 09578541 . Same 2024 PDF, page 34 · printed page 28 The 2024 definition also lists amendments in October 2021, December 2022 and June 2024, with a further amendment around the date of that deed. The original 2015 filing remains available under its own document link. Ask for the complete agreement trail Which documents connect the original State Bidco party, the later Ello name and each amendment? Which obligations continued, which changed, and how was that continuity explained to counterparties? Can the company supply a dated schedule linking each name, company number, agreement and amendment?", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzEyODQ3MDcxM2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzQ0MzQ1NjI3NGFkaXF6a2N4/document?format=pdf&download=0" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#replacement-filings", "heading": "Ello Group Holdings: compare the replacement filings.", "text": "Ello Group Holdings: compare the replacement filings. The register labels the 31 January 2026 share-class notice as replaced twice. The three linked forms contain different descriptions and figures for the same assignment date: 31 December 2025 . SH08 · notice of share-class name or designation · company 09685437 Filing-history date Existing shares stated New designation stated 31 January 2026 ↗ 22,280,281 preference shares of £0.00001 each A deferred shares of £0.01 each; no resulting quantity specified in this field 24 June 2026 ↗ 22,280,581 preference shares 22,281 A deferred shares of £0.01 each 29 August 2026 ↗ 22,280,581 preference shares of £0.00001 each 22,280,581 A deferred shares of £0.00001 each The filing history says the original contained an error. The August replacement form describes the original SH08 as containing incorrect information. The receipt stamps on the two replacement PDFs are 11 June and 18 August 2026 ; these are separate from their filing-history dates. Questions for the company’s record What specific error did each replacement address? Why do the share quantity and nominal value differ between the three versions? Which resolutions and share-register entries reconcile the designation change, the separately filed consolidation and the allotment? Which version describes the position at each stage of 31 December 2025, and who relied on the earlier versions before replacement? The related allotment filing: three date references to reconcile The history lists an SH01 replacement on 29 August 2026 . The annotation beneath the original entry dated 23 January 2026 instead says a replacement was registered on 29 September 2026 . The linked replacement application bears a receipt stamp of 18 August 2026 . Ask: Which date is the registration date for the replacement, and how should the two history references be reconciled? Open the linked SH01 and replacement application ↗ · Compare the register annotations ↗ Place the changes in sequence. The register also records control changes effective on 31 December 2025, filed in January 2026. Read those entries alongside the share documents and the published ownership chronology . Preserve the event, receipt, filing and replacement dates separately. Earlier replacement entries across the three companies Ello Group Holdings: a second filing on 25 November 2021 for its confirmation statement dated 13 July 2021. Spark Marketing Services: second filings on 7 April 2021 for confirmation statements dated 27 January 2017 and 27 January 2018. Ello Group: a PSC02 registered on 3 December 2025 replaces control information originally registered through its 10 May 2017 confirmation statement; the register describes the original as not properly delivered. These are the register’s replacement or second-filing labels. For each, ask which information changed and which underlying record supports it. Ello Group Holdings history ↗ · Spark history ↗ · Ello Group replacement PSC02 ↗", "sources": [ "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUwMTE2MDI2NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUyNzk4MDk1MmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzU0MTU4NDk0MmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUwMTE1OTcyN2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzQ5MjE5NDkwNmFkaXF6a2N4/document?format=pdf&download=0" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#web-history", "heading": "Keep a record when websites change.", "text": "Research tool · general guidance Keep a record when websites change. The Wayback Machine can help consumers and SMEs compare earlier versions of terms, policies and other public pages. Keeping dated copies helps readers follow changes in wording and identify periods where the historical record is harder to access. How to check pages and archived robots.txt files Compare the same page over time. Search its full address in Wayback and open saved versions before and after the period you are examining. Keep the capture date separate from any publication or effective date printed on the page. Look for archived crawler rules. Find /robots.txt among the archived URLs, or enter its full address directly. Compare dated captures of that file alongside the page captures. User-agent identifies the crawler group; Disallow and Allow set rules for matching paths. Read the relevant group and exceptions together. Record gaps precisely. Keep any exclusion or failed-capture message, the exact URL and the date checked. Archive coverage and the treatment of crawler rules vary; historical copies show the rules captured at that time. · Preserve what you can read. Keep the archive link and a dated local copy. For public pages you want to preserve now, try Save Page Now and check the resulting capture. Saving pages guide ↗ This creates a traceable record of changes and access restrictions that readers can examine and raise questions about. Open Wayback Machine ↗", "sources": [ "https://archivesupport.zendesk.com/hc/en-us/articles/360001513491-Save-Pages-in-the-Wayback-Machine", "https://web.archive.org/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#follow-corporate-events", "heading": "Follow ownership and event dates too.", "text": "Follow ownership and event dates too. A name change and a disposal are different events. Compare company numbers, effective dates and later filing or announcement dates. Read the public corporate-change chronology →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#corporate-records-example", "heading": "From register entries to a complete sequence.", "text": "From register entries to a complete sequence. See how names, disposals, financial presentation, reporting dates and adviser changes fit together in a fictional chronology. Open the interactive corporate-record example →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/record-changes.html#company-number-and-data-role", "heading": "Follow the company. Then follow its decisions.", "text": "Follow the company. Then follow its decisions. A company number identifies the legal entity. Its data-protection role depends on what it decides or does with the information in each processing activity. A single checkout can generate records used for order fulfilment, payment processing, fraud assessment and reporting. If an output is later linked to a customer profile or used for marketing, follow that later purpose and the entity deciding it. Calling a business a payment processor does not establish that it acts only as a processor under data-protection law. Identify each entity Record the company number behind the storefront, platform, payment service and receiving system. Keep the name and notice applicable at the time. Identify each decision Who chose the fields, identifiers, matching rules, purpose, recipients and retention period? What access did each organisation actually have? Trace the next use Which records connect the original capture to a report, export, profile or later decision? Ask who authorised that step and where it was explained to the person concerned. Organisations can be separate controllers for different uses, or joint controllers where they jointly determine the purposes and means of processing. A processor acts on a controller's instructions; an organisation that determines its own additional purpose must account for that activity in its own role. The same information appearing in more than one system makes the purpose-by-purpose account important. The question to put to the whole chain: Which legal company was responsible for each use, and where is the record connecting the handovers? ICO: controllers, joint controllers and processors ↗ · ICO: determine the role for each activity ↗ Explore the connected systems and responsibility questions → Ask for one complete account across the companies →", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/how-do-you-determine-whether-you-are-a-controller-or-processor/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/granular.html", "title": "Granular research guide", "sections": [ { "id": "https://filmpass.nsstudio.uk/granular.html#section-1", "heading": "Granular", "text": "RESEARCH FRAMEWORK · EDUCATIONAL OVERVIEW Granular Understanding how context, identifiers and decisions can travel through digital commerce. Prepared by FilmPass Ltd · Public education edition prepared 31 October 2026 Educational overview ↗ From the event to the system. From the event to the system. EVENT → CONTEXT → SYSTEM. The white paper develops the questions behind the shorter explainers. SYSTEM CONTEXT EVENT The white paper develops the questions behind the shorter explainers.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "From the event to the system. EVENT → CONTEXT → SYSTEM. The white paper develops the questions behind the shorter explainers. SYSTEM CONTEXT EVENT" ] }, { "id": "https://filmpass.nsstudio.uk/granular.html#framework", "heading": "Small records. Larger questions.", "text": "Small records. Larger questions. Granular is the research framework behind these explainers. It asks how individual events acquire context, how identifiers connect them and how later decisions can affect the people and businesses concerned. The redacted educational paper is available below. Private case evidence remains separate. Follow a data journey Collection, exposed fields and matching. ↗ Interactive explanations Purpose, interpretation and downstream consequences. ↗ Connections & customer knowledge Customer knowledge and an SME’s commercial role. ↗ Roles & responsibility Roles, instructions and responsibility. ↗ Consumer & SME transparency Practical questions and correction routes. ↗", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/granular.html#granular-download", "heading": "Download Granular.", "text": "Download Granular. Granular — Public Education Edition. A 96-page research paper on digital commerce, closed user groups, behavioural information and accountability. Research period: 23 December 2024–23 December 2025. Education edition prepared 31 October 2026. Follow the source event, separate the records, trace the connections and ask what happens next. The paper distinguishes documented capabilities, illustrative mechanisms and evidence of actual use. Download Granular — education PDF ↓", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/sources.html", "title": "Public sources & research notes", "sections": [ { "id": "https://filmpass.nsstudio.uk/sources.html#section-1", "heading": "Sources & research notes.", "text": "PUBLIC RESEARCH REFERENCES Sources & research notes. Follow the public documentation behind the explanations. These sources describe products, guidance and published methods.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/sources.html#publication-notes", "heading": "Our research and preserved records.", "text": "Our research and preserved records. Education edition prepared: 31 October 2026. This website brings together our educational research, technical explanations and public sources. Our original research, correspondence, disclosures, timelines and case documents are preserved privately while we follow the relevant processes. Keeping that material separate from this public resource does not mean it has been discarded or that the matters it concerns have been resolved. We will provide updates when appropriate and add further research and examples as they are reviewed. Source dates help readers place an explanation in its proper context. Product documentation and guidance can change, so compare the version and rules relevant to the event you are examining.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/sources.html#public-references", "heading": "Public reference directory.", "text": "Public reference directory. Links are carried forward from the explanatory pages. Their inclusion is not an independent audit or endorsement of a provider’s practices. Official technical source ↗ Used in: Follow a data journey , Interactive explanations , 20 technical questions , Connections & customer knowledge , Roles & responsibility , The value of linked data Sigma overview ↗ Used in: Follow a data journey , Connections & customer knowledge Fraud analysis and reporting fields ↗ Used in: Follow a data journey , Connections & customer knowledge Scheduled query results ↗ Used in: Follow a data journey Transactional data and customer joins ↗ Used in: Follow a data journey , Roles & responsibility Stripe: metadata and copying rules ↗ Used in: Follow a data journey , Interactive explanations , 20 technical questions , Connections & customer knowledge ICO: pseudonymisation ↗ Used in: Follow a data journey , 20 technical questions , Closed user groups & benefits ICO: indirect identification ↗ Used in: Follow a data journey FOS: fraud-marker complaints ↗ Used in: Interactive explanations Read the FOS case study ↗ Used in: Interactive explanations Cifas: processing, consequences and retention ↗ Used in: Interactive explanations ICO: accuracy of personal information ↗ Used in: Interactive explanations , 20 technical questions EMVCo history ↗ Used in: Interactive explanations FCA announcement ↗ Used in: Interactive explanations Visa’s dated bulletin ↗ Used in: Interactive explanations EMVCo: channels, messages and privacy responsibilities ↗ Used in: Interactive explanations , 20 technical questions , Connections & customer knowledge Visa: authentication, authorisation and the evolution of 3DS ↗ Used in: Interactive explanations ICO: responsibilities alongside international-transfer rules ↗ Used in: Interactive explanations Companies Act 2006, section 81 ↗ Used in: Interactive explanations , Reading names & records , Article 02 · Reward company identity , Article 03 · Corporate changes & records GOV.UK: registered office requirements ↗ Used in: Interactive explanations ICO: getting information corrected ↗ Used in: Interactive explanations , 20 technical questions ICO: restricting use ↗ Used in: Interactive explanations Configured destinations ↗ Used in: 20 technical questions Personal records and supporting information ↗ Used in: 20 technical questions What is personal data? ↗ Used in: 20 technical questions Identifiers and customer traits ↗ Used in: 20 technical questions Device context and separate authentication ↗ Used in: 20 technical questions Merchant-visible risk outcomes ↗ Used in: 20 technical questions Event notifications and delivery ↗ Used in: 20 technical questions Roles for each processing activity ↗ Used in: 20 technical questions , Reading names & records Events and their properties ↗ Used in: 20 technical questions Observed and inferred information; intelligibility ↗ Used in: 20 technical questions Reporting and CSV exports ↗ Used in: 20 technical questions Access and data sharing ↗ Used in: 20 technical questions Transforming destination events ↗ Used in: 20 technical questions Finding and retrieving information ↗ Used in: 20 technical questions Further purposes ↗ Used in: 20 technical questions , Connections & customer knowledge Ordinary legitimate interests ↗ Used in: 20 technical questions Recognised legitimate interest ↗ Used in: 20 technical questions , Consumer & SME transparency Deletion and suppression coverage ↗ Used in: 20 technical questions Event delivery visibility ↗ Used in: 20 technical questions Radar analytics Used in: 20 technical questions ICO: when to provide privacy information Used in: 20 technical questions ICO: relevant SAR exemptions Used in: 20 technical questions ICO: business-to-business marketing Used in: 20 technical questions ICO: controllers and processors Used in: 20 technical questions , Connections & customer knowledge , Roles & responsibility , Reading names & records Authentication data categories and conditional fields Used in: Connections & customer knowledge Review API fields and authenticated access Used in: Connections & customer knowledge Configured cross-region and cross-cloud replication Used in: Connections & customer knowledge Sharing across regions and cloud platforms Used in: Connections & customer knowledge Invoice creation from storefront orders Used in: Connections & customer knowledge CRM-to-destination connector and field access Used in: Connections & customer knowledge Marketing-platform profile fields Used in: Connections & customer knowledge Published demographic-enrichment example Used in: Connections & customer knowledge Platform and connected-account events Used in: Connections & customer knowledge , Roles & responsibility , Closed user groups & benefits Platform/connected-account charge arrangements Used in: Connections & customer knowledge , Roles & responsibility CMA research on algorithmic competition risks Used in: Connections & customer knowledge , Consumer & SME transparency ICO: who the UK GDPR applies to ↗ Used in: Roles & responsibility ICO: international transfers ↗ Used in: Roles & responsibility ICO: sharing information for fraud prevention Used in: Roles & responsibility , Consumer & SME transparency , The value of linked data , Closed user groups & benefits ICO fairness and transparency guidance ↗ Used in: Consumer & SME transparency Data (Use and Access) Act 2025 ↗ Used in: Consumer & SME transparency Section 71: purpose limitation ↗ Used in: Consumer & SME transparency ICO: compatibility and reuse ↗ Used in: Consumer & SME transparency GOV.UK: commencement dates ↗ Used in: Consumer & SME transparency Tesco Media / dunnhumby Used in: The value of linked data Tesco privacy and cookies policy Used in: The value of linked data NCSC data-breach guidance Used in: The value of linked data Home Office guidance on failure to prevent fraud Used in: The value of linked data Planit, Importance of Closed User Groups Used in: The value of linked data , Closed user groups & benefits Impact Contribution Report documentation Used in: The value of linked data AppsFlyer incrementality experiment documentation Used in: The value of linked data Name history ↗ Used in: Reading names & records , Public records & research examples 2022 filings ↗ Used in: Reading names & records Name history ↗ Used in: Reading names & records , Public records & research examples 2022 filings ↗ Used in: Reading names & records Name history ↗ Used in: Reading names & records , Public records & research examples 2022 filings ↗ Used in: Reading names & records Original accounts, cover page ↗ Used in: Reading names & records Original accounts, cover page ↗ Used in: Reading names & records , Public records & research examples Original accounts, cover page ↗ Used in: Reading names & records , Public records & research examples Original three-page filing: certificate and resolution ↗ Used in: Reading names & records , Public records & research examples Taste Marketing · control register Used in: Reading names & records , Public records & research examples Open the two PSC entries ↗ Used in: Reading names & records , Public records & research examples PSC07 ↗ Used in: Reading names & records PSC05 ↗ Used in: Reading names & records PSC02 ↗ Used in: Reading names & records December PSC05 ↗ Used in: Reading names & records Read the complete State Debtco filing sequence ↗ Used in: Reading names & records , Public records & research examples Debenture dated 3 August 2015 ↗ Used in: Reading names & records Debenture dated 13 November 2024 ↗ Used in: Reading names & records 31 January 2026 ↗ Used in: Reading names & records 24 June 2026 ↗ Used in: Reading names & records 29 August 2026 ↗ Used in: Reading names & records Open the linked SH01 and replacement application ↗ Used in: Reading names & records Compare the register annotations ↗ Used in: Reading names & records , Public records & research examples Spark history ↗ Used in: Reading names & records , Article 03 · Corporate changes & records Ello Group replacement PSC02 ↗ Used in: Reading names & records Saving pages guide ↗ Used in: Reading names & records Open Wayback Machine ↗ Used in: Reading names & records Read the transparency requirements ↗ Used in: Closed user groups & benefits , Article 01 · Corporate cinema ticket journeys , Article 02 · Reward company identity ICO: valid consent Used in: Closed user groups & benefits Planning direct marketing Used in: Closed user groups & benefits ICO: the right to object Used in: Closed user groups & benefits iCOUNTER: research report, 25 August 2026 ↗ Used in: Closed user groups & benefits Cybernews: reported data categories and linkage ↗ Used in: Closed user groups & benefits Read the original public thread ↗ Used in: Closed user groups & benefits Stripe: API key access and incident handling ↗ Used in: Closed user groups & benefits Stripe: connected-platform access and revocation ↗ Used in: Closed user groups & benefits Read the migration guide ↗ Used in: Closed user groups & benefits Compare the prior terms, PDF pages 9–10 ↗ Used in: Closed user groups & benefits Read the notice ↗ Used in: Closed user groups & benefits Read the researchers’ account ↗ Used in: Closed user groups & benefits Read the UK agreement ↗ Used in: Closed user groups & benefits Read the applicability and notification dates ↗ Used in: Closed user groups & benefits API permissions and access policies ↗ Used in: Closed user groups & benefits Privacy roles and retention ↗ Used in: Closed user groups & benefits ICO: deciding controller and processor roles ↗ Used in: Closed user groups & benefits ICO: tracking technologies and link decoration Used in: Closed user groups & benefits Tracking within email Used in: Closed user groups & benefits ICO: profiling and enrichment ↗ Used in: Closed user groups & benefits Linkability and identifiability Used in: Closed user groups & benefits NPSA: digital footprints and online targeting Used in: Closed user groups & benefits Protecting information about you Used in: Closed user groups & benefits Recognising targeted approaches Used in: Closed user groups & benefits HMRC VAT Notice 700/7, section 9 ↗ Used in: Closed user groups & benefits ICO handles data-protection concerns Used in: Closed user groups & benefits ASA advertising and promotion complaints Used in: Closed user groups & benefits CMA reporting guidance Used in: Closed user groups & benefits Read the ASA ruling and response → Used in: Public records & research examples Company RNS announcement held by the FCA Used in: Public records & research examples , Article 03 · Corporate changes & records Acquisition adviser's published account Used in: Public records & research examples 09578541 · Filing document Used in: Public records & research examples 09578541 · Filing document Used in: Public records & research examples 03940640 · Filing document Used in: Public records & research examples 03940640 · Filing document Used in: Public records & research examples 03940640 · Filing document Used in: Public records & research examples 05545626 · Filing document Used in: Public records & research examples 05545626 · Filing document Used in: Public records & research examples 09685583 · Filing document Used in: Public records & research examples 09685583 · Filing document Used in: Public records & research examples 03988503 · Filing history Used in: Public records & research examples 05119718 · Filing history Used in: Public records & research examples 05119718 · Control register Used in: Public records & research examples DNS record reference Used in: Article 01 · Corporate cinema ticket journeys CNAME records — aliasing explained Used in: Article 01 · Corporate cinema ticket journeys Companies House — check a company and its name history Used in: Article 02 · Reward company identity LSE · AIM Rules for Companies Used in: Article 03 · Corporate changes & records LSE · AIM Rules for Nominated Advisers Used in: Article 03 · Corporate changes & records LSE · SETSqx trading service Used in: Article 03 · Corporate changes & records Companies House · accounts and subsidiary exemptions Used in: Article 03 · Corporate changes & records Issuer results centre · compare successive annual and interim reports Used in: Article 03 · Corporate changes & records", "sources": [ "https://docs.stripe.com/disputes/prevention/advanced-fraud-detection", "https://docs.stripe.com/data/sigma", "https://stripe.com/guides/improve-fraud-management-with-radar-and-stripe-data", "https://docs.stripe.com/data/schedule-queries", "https://docs.stripe.com/data/query-transactions", "https://docs.stripe.com/metadata", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/can-we-identify-an-individual-indirectly/", "https://www.financial-ombudsman.org.uk/consumers/complaints-can-help/fraud-scams/fraud-markers", "https://www.financial-ombudsman.org.uk/businesses/resolving-complaint/case-studies/consumer-complains-pricing-mistake-made-insurance-policy", "https://www.cifas.org.uk/fpn", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/", "https://www.emvco.com/why-emv/", "https://www.fca.org.uk/news/statements/deadline-extension-strong-customer-authentication", "https://www.visa.co.uk/content/dam/VCOM/regional/na/us/support-legal/documents/visa-will-discontinue-support-for-3ds.pdf", "https://www.emvco.com/emv-technologies/3-d-secure/", "https://corporate.visa.com/en/solutions/visa-protect/insights/3d-secure.html", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/what-are-our-other-key-uk-gdpr-obligations-in-the-context-of-international-transfers/", "https://www.legislation.gov.uk/ukpga/2006/46/section/81", "https://www.gov.uk/limited-company-formation/company-address", "https://ico.org.uk/for-the-public/your-right-to-get-your-data-corrected/", "https://ico.org.uk/for-the-public/your-right-to-limit-how-organisations-use-your-data/", "https://www.twilio.com/docs/segment/connections/destinations", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/what-is-the-right-of-access/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-is-personal-data/", "https://www.twilio.com/docs/segment/connections/spec/identify", "https://www.emvco.com/knowledge-hub/supporting-the-deployment-of-emv-3-d-secure-solutions/", "https://docs.stripe.com/radar/transaction-risk-prevention", "https://docs.stripe.com/webhooks", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/how-do-you-determine-whether-you-are-a-controller-or-processor/", "https://www.twilio.com/docs/segment/connections/spec/track", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/how-can-we-supply-information-to-the-requester/", "https://stripe.com/sigma/pricing", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/data-sharing-covered-by-the-code/", "https://www.twilio.com/docs/segment/connections/functions/insert-functions", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/how-do-we-find-and-retrieve-the-relevant-information/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/purpose-limitation/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/legitimate-interests/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/recognised-legitimate-interest/", "https://www.twilio.com/docs/segment/privacy/user-deletion-and-suppression", "https://www.twilio.com/docs/segment/connections/delivery-overview", "https://docs.stripe.com/radar/analytics", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/the-right-to-be-informed/when-should-we-provide-privacy-information/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/what-exemptions-are-relevant-for-sars/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/business-to-business-marketing/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/", "https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/improving-risk-emv-3-d-secure-whitepaper-v2-analysis-and-frictionless-flow/technical-features/", "https://developers.trustpilot.com/service-reviews-api", "https://docs.snowflake.com/en/user-guide/account-replication-intro", "https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-platforms", "https://sufio.com/articles/shopify/create-documents-orders/create-invoices/", "https://fivetran.com/docs/connectors/applications/salesforce", "https://support.iterable.com/hc/en-us/articles/206430145-Managing-User-Profile-Fields-in-Iterable", "https://www.caci.co.uk/insights/how-marie-curie-use-data-insights-to-improve-supporter-engagement-increase-income/", "https://docs.stripe.com/connect/webhooks", "https://docs.stripe.com/connect/charges", "https://www.gov.uk/government/publications/algorithms-how-they-can-reduce-competition-and-harm-consumers/algorithms-how-they-can-reduce-competition-and-harm-consumers", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/who-does-the-uk-gdpr-apply-to/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-information-when-preventing-detecting-and-investigating-scams-and-frauds/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/lawfulness-fairness-and-transparency/", "https://www.legislation.gov.uk/ukpga/2025/18/contents", "https://www.legislation.gov.uk/ukpga/2025/18/section/71", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/compatibility-and-the-reuse-of-personal-information/", "https://www.gov.uk/guidance/data-use-and-access-act-2025-plans-for-commencement", "https://www.dunnhumby.com/tesco-media/", "https://www.tesco.com/shop/en-GB/zone/privacy-and-cookies-policy", "https://www.ncsc.gov.uk/guidance/data-breaches", "https://www.gov.uk/government/publications/offence-of-failure-to-prevent-fraud-introduced-by-eccta", "https://www.planit.co.uk/post/importance-of-closed-user-groups", "https://help.impact.com/brand/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-reports/contribution-report", "https://support.appsflyer.com/hc/en-us/articles/360014225577-Run-an-Incrementality-for-remarketing-experiment", "https://find-and-update.company-information.service.gov.uk/company/09685437", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history?page=2", "https://find-and-update.company-information.service.gov.uk/company/09578541", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history?page=2", "https://find-and-update.company-information.service.gov.uk/company/09975027", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history?page=2", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzMzOTM5MTI2MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzOTM5MjE5OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzM1MTM2ODkzOGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history/MzMyOTc3Nzk4N2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/05545626/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09685583/persons-with-significant-control", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzg0NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzY2N2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNTk1MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ5NTIyMDA0MGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzEyODQ3MDcxM2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzQ0MzQ1NjI3NGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUwMTE2MDI2NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUyNzk4MDk1MmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzU0MTU4NDk0MmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history/MzUwMTE1OTcyN2FkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685437/filing-history", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzQ5MjE5NDkwNmFkaXF6a2N4/document?format=pdf&download=0", "https://archivesupport.zendesk.com/hc/en-us/articles/360001513491-Save-Pages-in-the-Wayback-Machine", "https://web.archive.org/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/consent/what-is-valid-consent/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/plan-direct-marketing/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-object/", "https://icounter.com/blog/why-compromised-apis-are-a-supply-chain-threat", "https://cybernews.com/security/stripe-data-breach-cybercrime-forum/", "https://www.reddit.com/r/stripe/comments/1vlydm6/stripe_has_apparently_absolutely_no_security/", "https://docs.stripe.com/keys-best-practices", "https://docs.stripe.com/connect/oauth-reference#revoke-the-accounts-access", "https://support.stripe.com/questions/plugin-user-migration-guide?locale=en-GB", "https://assets.stripeassets.com/fzn2n1nzq965/TJYsZOVIGObEhuOKwIN6u/365201c88376e26bb451727a4aff47f0/Stripe_Services_Agreement_-_General_Terms.pdf", "https://stripe.com/legal/api-key-security", "https://www.infostealers.com/article/analyzing-stripe-breach-confirmed-vendor-exposure-and-claims-of-20000-compromised-apis/", "https://stripe.com/gb/legal/ssa", "https://support.stripe.com/questions/stripe-user-terms-update-september-28-2026?locale=en-GB", "https://docs.stripe.com/keys", "https://stripe.com/legal/privacy-center", "https://cy.ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors-a-guide/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-storage-and-access-technologies/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/what-else-do-we-need-to-consider/", "https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/collect-information-and-generate-leads/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/how-do-we-ensure-anonymisation-is-effective/", "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/be-vigilant-online", "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/protect-information-about-you", "https://www.npsa.gov.uk/specialised-guidance/personal-safety-security-high-risk-individuals/are-you-being-targeted-or-someone-trying-access-your-information-or-accounts", "https://www.gov.uk/guidance/business-promotions-and-vat-notice-7007", "https://ico.org.uk/for-the-public/how-to-make-a-data-protection-complaint/", "https://www.asa.org.uk/make-a-complaint.html", "https://www.gov.uk/guidance/how-best-to-make-a-competition-or-consumer-law-complaint-and-what-happens-next", "https://www.asa.org.uk/rulings/taste-marketing-ltd-a22-1155526-taste-marketing-ltd.html", "https://data.fca.org.uk/artefacts/NSM/RNS/61890f2f-0595-4656-9319-8433aeb41f9a.html", "https://www.shma.co.uk/our-thoughts/shakespeare-martineau-advises-dragonpass-major-uk-acquisition/", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzOTM5MTcxOGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09578541/filing-history/MzMzMDI5NTIzNmFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MDM2OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MDc1NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/03940640/filing-history/MzMzMjE5MjY3NWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/05545626/filing-history/MzMzMjE5MzM2NGFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/05545626/filing-history/MzMzMjE5MzM2OWFkaXF6a2N4/document?format=pdf&download=0", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNzg0NWFkaXF6a2N4/document?download=0&format=pdf", "https://find-and-update.company-information.service.gov.uk/company/09685583/filing-history/MzQ3NzUzNTk1MGFkaXF6a2N4/document?download=0&format=pdf", "https://find-and-update.company-information.service.gov.uk/company/03988503/filing-history", "https://find-and-update.company-information.service.gov.uk/company/05119718/filing-history", "https://find-and-update.company-information.service.gov.uk/company/05119718/persons-with-significant-control", "https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/", "https://www.cloudflare.com/learning/dns/dns-records/dns-cname-record/", "https://find-and-update.company-information.service.gov.uk/", "https://www.londonstockexchange.com/content/dam/lse/en_us/documents/rules-and-regulations/aim-rules-for-companies.pdf", "https://www.londonstockexchange.com/content/dam/lse/en_us/documents/rules-and-regulations/aim-rules-for-nominated-advisers.pdf", "https://www.londonstockexchange.com/en/markets-products/asset-classes/shares/setsqx-and-seaq", "https://www.gov.uk/government/publications/filing-your-companies-house-accounts/life-of-a-company-part-1-accounts", "https://www.themission.co.uk/investors/results-centre/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/sources.html#research-formats", "heading": "Research formats: GEO, RAG and JSON-LD.", "text": "Research formats: GEO, RAG and JSON-LD. The same visible educational content is available as a structured research corpus for retrieval-augmented generation (RAG), with page and section identifiers, source links and diagrams described in text. GEO means making this material understandable and attributable to generative search systems; it is not a promise of inclusion or endorsement. Each chapter contains Schema.org JSON-LD. The technical questions page also describes its 20 visible questions and answers as FAQPage data. Sources remain attributed to their publishers; a cited commercial claim is not converted into an independently verified fact. The downloads contain public educational material only. They exclude private correspondence, case timelines and evidence schedules. A source listed for a section provides context, not blanket verification of every sentence. Research corpus / RAG JSON ↓ JSON Schema ↓ Research index ↓ Google Search Central: AI features and your website", "sources": [ "https://developers.google.com/search/docs/appearance/ai-features" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/privacy.html", "title": "Privacy notice", "sections": [ { "id": "https://filmpass.nsstudio.uk/privacy.html#section-1", "heading": "Privacy notice.", "text": "YOUR INFORMATION Privacy notice. How FilmPass Ltd handles information connected with this educational website and enquiries. Last updated: 3 November 2026", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/privacy.html#responsible", "heading": "Who is responsible?", "text": "Who is responsible? Email address Copy email address If the email link does not open your mail app, copy this address into a new message. FilmPass Ltd is responsible for this publication and handling enquiries. FilmPass & Co is the publication’s display name. For privacy enquiries or requests, contact FilmPass .", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/privacy.html#enquiries", "heading": "If you contact us.", "text": "If you contact us. We receive your email address, any name you provide and your message. We use this to respond, consider feedback and keep a proportionate record of the enquiry. Our basis is legitimate interests in maintaining an accurate publication and responding to people who contact us, taking their interests into account. Where required by law, we rely on the relevant legal obligation. Please do not send medical records, identity documents or payment-card details in an initial message. Contact is voluntary; we may need enough information to understand and answer your request. We do not use enquiries for advertising or publish them.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/privacy.html#technology", "heading": "Website technology and service providers.", "text": "Website technology and service providers. FilmPass uses Cloudflare Web Analytics to understand visits, page views, countries, referring websites where available, and page performance. A script in the browser sends measurement information to Cloudflare, and we use the resulting reports to understand how this educational resource is used. Cloudflare states that this analytics service does not use cookies or local storage, or fingerprint individuals, to collect usage metrics. FilmPass does not use these reports for advertising, CRM enrichment or identifying individual visitors. The interactive examples run in your browser using invented records. The site does not submit an enquiry form. FilmPass does not run advertising tags, fraud-prevention scripts or session recording on this reader. Cloudflare Pages provides hosting and delivery for this domain and may process IP addresses and request information to deliver and secure the service. The pages use fonts already available on your device and do not request fonts from an external service. Hosting and analytics involve processing information; a static educational website is not the same as a website that processes no information. Cloudflare privacy information Cloudflare Web Analytics information Google Workspace provides email services for enquiries. Information is handled by people authorised by FilmPass and, where necessary, relevant professional advisers or authorities. Google services may involve processing outside the UK; see Google’s privacy information and Google’s Workspace Data Processing Addendum . We will update this notice if the hosting or features change.", "sources": [ "https://www.cloudflare.com/privacypolicy/", "https://policies.google.com/privacy", "https://workspace.google.com/terms/dpa_terms.html" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/privacy.html#retention", "heading": "Retention and your rights.", "text": "Retention and your rights. We retain enquiry information for as long as needed to respond, review feedback and account for our handling, or meet applicable legal requirements. We review whether continued retention is necessary and delete or anonymise information no longer needed. Depending on the circumstances, you can request access, correction, erasure, restriction or portability, and object to processing based on legitimate interests. Contact the address above. We do not make solely automated decisions about enquiries. You can also complain to the Information Commissioner’s Office .", "sources": [ "https://ico.org.uk/make-a-complaint/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/privacy.html#scope", "heading": "Public content and enquiries.", "text": "Public content and enquiries. This edition contains our account of why research began, general explanations, fictional examples and public references. It does not contain the private evidence archive or case-document access links. If content identifies you unnecessarily or contains inaccurate personal information, tell us the page and passage so we can review it.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/research-articles.html", "title": "Blogs", "sections": [ { "id": "https://filmpass.nsstudio.uk/research-articles.html#section-1", "heading": "Blogs.", "text": "THE GROWING RESEARCH LIBRARY Blogs. Educational explainers, organised by topic. Each article has a stable number, its own page and an identified source-review date. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/research-articles.html#article-directory", "heading": "Browse the research.", "text": "Browse the research. ARTICLE 01 · TICKET JOURNEYS & RESPONSIBILITY Who handles a corporate cinema ticket benefit? Explore how the brand-facing journey relates to fulfilment, hosting, mail and support services. Includes an interactive service-layer example and consumer questions. Prepared and sources reviewed 1 November 2026 · Fictional teaching example Read Article 01 → ARTICLE 02 · COMPANY IDENTITY & CHANGING TERMS Same group. Which company runs the reward? Use the moving-card example to distinguish a company name change from a different subsidiary being named as operator. Follow earlier contracts, support roles and information responsibilities. Prepared 1 November 2026 · Fictional teaching example Read Article 02 → ARTICLE 03 · CORPORATE CHANGES & RECORDS Corporate changes. Keep the history visible. Switch between a current group summary and the preserved event record. Follow disposals, reporting changes, adviser appointments and off-book trade terminology. Explore the corporate-record example →", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/research-articles.html#article-method", "heading": "How this collection develops.", "text": "How this collection develops. Articles turn research questions into general teaching examples, using fictional roles and changing unnecessary identifying details. Public references explain the documented capabilities; assumed connections and unresolved questions remain labelled. Stable article numbers help readers find and cite a piece as the collection grows. The date on an article identifies its preparation or review; it does not establish the date of earlier private research. Private case records are maintained separately.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html", "title": "Article 01 · Corporate cinema ticket journeys", "sections": [ { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-1", "heading": "Who handles a corporate cinema ticket benefit?", "text": "RESEARCH ARTICLE 01 · TICKET JOURNEYS & RESPONSIBILITY Who handles a corporate cinema ticket benefit? Follow a fictional corporate cinema ticket journey through its brand presentation, service layers, domains and information responsibilities. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-2", "heading": "The question behind the branding", "text": "The question behind the branding A member follows a cinema offer from a familiar benefits service. The landing page carries recognisable branding, but the redemption address and help email use another domain. A software-licensing footer names another organisation again. The change can be easy to miss: visual continuity can feel like organisational continuity. The questions are who operates each step, what information reaches them, and whether the explanation available to the member matches that route. This example uses invented roles and addresses. It does not reconstruct a particular promotion.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-3", "heading": "One journey. Several service layers.", "text": "One journey. Several service layers. Reveal service layers Member view: the offer, the ticket and a place to ask for help. 01 Benefits offer Member follows the branded offer. → 02 Ticket page Member claims a cinema code. → 03 Support or redemption Member uses the code or asks for help. Offer publisher Sets eligibility and presents the benefit. Ask who chose the delivery partners and what information is passed when the member follows the offer. Fulfilment operator Runs the claim journey or issues codes. Ask who receives form details, stores entitlement records and decides how those records are used. Mail, support and redemption services May receive messages, delivery events or code-use records. Each is a separate route to establish; a shared logo does not describe these relationships. Infrastructure underneath the page claim.ticket-benefit.example may resolve to a hosting or delivery service. help@ticket-benefit.example can use a separate mail provider. A link or event service may be configured on another hostname. These addresses are fictional. DNS can help identify service relationships, but it does not reveal the full application, contractual or personal-data flow. The service layers are: offer publisher, fulfilment operator, hosting/delivery provider, and separate mail/support or redemption services. Their roles need separate evidence. All service connections are assumed for this teaching example. No live lookup, tracking or ticket transaction is performed.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-4", "heading": "What a DNS record can—and cannot—answer", "text": "What a DNS record can—and cannot—answer Clue What it describes What to establish next A / AAAA An address associated with a hostname. A proxy or delivery network may sit in front of the origin. Who operates the application, and which infrastructure actually handles the request? CNAME An alias to another hostname. It does not itself cause a browser redirect. Which configured service answers for this hostname? MX Mail-delivery routing for the domain. Who can access a support message, and where is it retained? NS The authoritative nameservers for the domain. Who controls DNS changes, separately from the website and business? Historic records / shared IP A record observed at a time, or multiple domains using an address. Was it the same operator and period? Shared hosting or parking alone does not establish common ownership or conduct. DNS hosting, domain registration, IP-network ownership and data controllership are different roles. A provider’s headquarters does not establish the server location or prove an international data transfer. An encrypted connection also does not establish who determines the business purpose. These distinctions follow the technical functions of the record types described in the DNS record reference .", "sources": [ "https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-5", "heading": "Where the explanation can leave a gap", "text": "Where the explanation can leave a gap A notice may explain ticket delivery at a high level while leaving a member unsure which organisation handles a claim, support message or later event. Compare the offer terms, the claim-page privacy notice and the support route as separate records. UK privacy guidance requires information including the identity of the controller, purposes and lawful basis, and recipients or categories of recipients. It does not follow that every infrastructure supplier must be individually named in the promotion’s terms. The practical question is whether the applicable privacy information explains the processing clearly enough. See the ICO’s right-to-be-informed guidance . A reference in a copyright or licensing footer may identify a software role. It does not, by itself, settle who determines each use of personal information. Similarly, a hostname containing “tracking” is a lead to investigate, not proof that tracking occurred during a particular visit.", "sources": [ "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-6", "heading": "From a support event to another use", "text": "From a support event to another use A claim reference, support message and redemption event may be separate records. If an integration can access them and a matching key exists, they could be joined to an order or customer record. A later analytical or marketing use is a further step to establish; it cannot be read directly from DNS. The important transition is from delivering or supporting a ticket to making a new use of the resulting information. Ask which fields moved, which identifiers connected them, what purpose was recorded and who chose the later use.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#international-service-chain", "heading": "A local promotion can involve an international service chain.", "text": "A local promotion can involve an international service chain. A corporate cinema benefit advertised to UK members may use a fulfilment operator, hosting service or support provider in another country. If that role is not clear from the information provided, the consumer may struggle to identify who handles their details and where to direct a request. Ask: Which organisation receives my information? Where is it stored and accessed? Which entity determines its use, and who must respond if I need an explanation or correction? A provider’s headquarters or DNS records alone do not establish overseas hosting. Processing outside the country where a promotion is offered is not automatically outside UK law. Establish the actual service, receiving entity and route before drawing that conclusion.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#international-service-chain", "heading": "A local promotion can involve an international service chain.", "text": "A local promotion can involve an international service chain. A corporate cinema benefit advertised to UK members may use a fulfilment operator, hosting service or support provider in another country. If that role is not clear from the information provided, the consumer may struggle to identify who handles their details and where to direct a request. Ask: Which organisation receives my information? Where is it stored and accessed? Which entity determines its use, and who must respond if I need an explanation or correction? A provider’s headquarters or DNS records alone do not establish overseas hosting. Processing outside the country where a promotion is offered is not automatically outside UK law. Establish the actual service, receiving entity and route before drawing that conclusion.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-9", "heading": "Questions a member or SME can ask", "text": "Questions a member or SME can ask Who operates the ticket-claim page, and which legal entity is responsible for my information at that step? What information is passed from the benefit service: an entitlement token, my identity, or other fields? Who can read a support message and connect it to my ticket, order or membership? Does redemption create an event record? Who receives it, and for what purposes? Are delivery or click events collected? Which records explain the configuration and applicable choices? Can claim, support or redemption records be exported or joined to a CRM? What fields and matching keys are used? Where are records stored and accessed, and which organisations receive them? Which notice applied at the time, and how can I request an explanation of my own information?", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-10", "heading": "How to examine the route", "text": "How to examine the route Preserve a dated copy of the offer, claim-page address, notices and support instructions. Record the DNS lookup type and observation date. Then distinguish each public technical clue from the application settings, contracts, event logs or recipient information needed to establish the actual flow. The purpose is to turn a familiar brand journey into answerable questions.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-01-corporate-cinema-tickets.html#section-11", "heading": "Public technical and privacy references", "text": "Public technical and privacy references DNS record types — technical reference CNAME records — aliasing explained Right to be informed — UK privacy guidance Public sources checked 1 November 2026. Generalised teaching example; private case records are maintained separately.", "sources": [ "https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/", "https://www.cloudflare.com/learning/dns/dns-records/dns-cname-record/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html", "title": "Article 02 · Reward company identity", "sections": [ { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-1", "heading": "Same group. Which company runs the reward?", "text": "RESEARCH ARTICLE 02 · COMPANY IDENTITY & CHANGING TERMS Same group. Which company runs the reward? Follow a fictional reward programme through company name changes and a change in the subsidiary named for a role. Keep each legal identity visible. Research guide ↗ A benefit. A purchase. A person. ELIGIBILITY PURCHASE REDEMPTION LATER USE? Separate the records. Establish each connection.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ELIGIBILITY PURCHASE REDEMPTION LATER USE?" ] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-2", "heading": "What stays familiar—and what changes?", "text": "What stays familiar—and what changes? A member sees the same reward programme, cinema offer and group branding. Earlier terms name one subsidiary; later terms name another. Meanwhile, a former company name remains in an older document and the support address uses a group brand. This can make several different events look like a single rebrand. The example below separates a name change within a company from a change in the subsidiary named for a role.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-3", "heading": "Flip the published arrangement.", "text": "Flip the published arrangement. Show later arrangement Earlier view: the programme names Company A as operator and uses Company B’s support brand. GROUP HOLDING COMPANY · Same parent group in both views Member-facing brand Named ticket operator Support / delivery service REWARD BRAND Members’ Cinema Reward The programme name remains unchanged. A brand is not a legal company number. SUBSIDIARY A Company A · former name Earlier terms: ticket operator Stable identity: COMPANY A SUBSIDIARY B Company B · former name Support brand / service Stable identity: COMPANY B Now distinguish the changes. A’s current name is still A. Its legal identity continues through the rename. B’s current name is still B. It remains a separate company in the same group. The later terms in this invented scenario name B as the operator and describe A as a delivery/support service. The card movement represents a change in the published role—not proof of a transfer of an earlier contract, liability or customer database. What documents establish any actual handover, its effective date and the position for existing members? Later arrangement: Company B, under its current name, is named as operator. Company A, under its current name, is described as a delivery/support service. Both remain separate subsidiaries of the same group. Earlier obligations and data use require separate examination. Illustrative role swap. The names, group and sequence are invented. No real company, group, registration number, domain or promotion is represented. The whole programme need not move for one role to change.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-4", "heading": "Keep two identity trails.", "text": "Keep two identity trails. Company Earlier display Later display What remains distinct A A’s former name; named as operator A’s current name; described as service provider A is the same legal company through its rename. B B’s former name; support brand/service B’s current name; named as operator B is separate from A, despite the common group. Reward brand Members’ Cinema Reward Members’ Cinema Reward Brand continuity does not identify which company performs each role. A company number is the practical anchor when checking a UK company’s name history. A name change does not erase the company’s rights or obligations. See Companies Act 2006, section 81 . A different subsidiary being named raises a different question: did a contract or operational role actually move, or did the website wording change? A revised page alone does not settle the arrangements for earlier purchases.", "sources": [ "https://www.legislation.gov.uk/ukpga/2006/46/section/81" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-5", "heading": "What can make the picture difficult to follow?", "text": "What can make the picture difficult to follow? One brand, several companies: the visible reward remains familiar while terms refer to different legal entities. Older names in newer material: a former name may persist in a notice, footer or support template. Compare the company number and document date. Shared support: a group email brand may serve more than one subsidiary. The domain alone does not identify the contracting company or who determines data use. Different versions of terms: an archive capture shows material available at the capture time; it does not automatically establish when wording was first published or which version a member accepted. Different scheme rules: one benefit may permit purchases for family or friends while another limits resale. Compare scope, audience and the applicable contract before calling the rules contradictory.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-6", "heading": "Questions for a member or SME", "text": "Questions for a member or SME Which company and registration number were named when I joined, paid or redeemed? Is the new name the same legal company, or a different group subsidiary? What changed: the name, operator, contract, support function or data-processing role? When did the change take effect, and how were existing members informed? Who remains responsible for earlier ticket purchases, refunds and unresolved enquiries? If information moved between subsidiaries, what information, recipient, purpose and explanation accompanied that move? Who decides how my information is used at each stage, and who must answer a request about it? Can you provide the terms and privacy information that applied to my transaction?", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-7", "heading": "Where to start examining the change", "text": "Where to start examining the change Compare dated terms, the company-number and name-history trail, support instructions and any recorded handover. Keep contractual responsibility separate from customer-service branding and data-processing responsibility. If two subsidiaries access or receive the same information, identify the actual access, transfer, fields and purposes. Membership of the same group does not, by itself, establish either that information was shared or that a particular sharing arrangement is justified. The distinction worth preserving is simple: same name does not guarantee the same operator; a different name does not necessarily mean a different company.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-02-reward-company-identity.html#section-8", "heading": "Public references", "text": "Public references Companies Act 2006, section 81 — effect of a company name change Companies House — check a company and its name history ICO — information about identity, purposes and recipients Prepared 1 November 2026. Fictional teaching scenario. No source screenshots, names, addresses, domains or case chronology are reproduced.", "sources": [ "https://www.legislation.gov.uk/ukpga/2006/46/section/81", "https://find-and-update.company-information.service.gov.uk/", "https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html", "title": "Article 03 · Corporate changes & records", "sections": [ { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#section-1", "heading": "Corporate changes. Keep the history visible.", "text": "RESEARCH ARTICLE 03 · CORPORATE RECORDS Corporate changes. Keep the history visible. When a company changes its structure or its story, follow the earlier event through the new presentation. Keep the sequence 03 The story changes. The record remains. ORIGINAL EVENT COMPANY ID LATER CHANGE DATED RECORD Connect the earlier question to the current answer.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "ORIGINAL EVENT COMPANY ID LATER CHANGE DATED RECORD" ] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#why-history-matters", "heading": "A changing business can leave an earlier question behind.", "text": "A changing business can leave an earlier question behind. An SME asks about a transaction. While that question remains open, a supplier changes its brand, sells a subsidiary, reorganises its services or appoints new advisers. The latest website and results presentation describe the current business. The SME still needs an answer about the business as it was when the transaction took place. The vulnerability is a break in the explanation: a statement about today is used in place of an answer about yesterday. A dated event log lets the reader connect the two. Fictional teaching example. Company A, Company B, Group G and the periods below are invented. Public references explain the record types; private case material is kept separately.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#history-comparison", "heading": "Switch between the latest story and the preserved record.", "text": "Switch between the latest story and the preserved record. Same events. Different visibility. Latest summary Show the preserved history THE CURRENT PRESENTATION A simpler group. A new operating structure. Group G now concentrates on two lead brands. Earlier activities have been sold. Performance is presented for the continuing business, a new reporting calendar is in place and a new nominated adviser has been appointed. Company B is now named as the service contact. The SME’s unanswered question: Who operated the service and held the relevant records when we purchased—and who can explain that earlier transaction now? The summary tells the reader what the group looks like today. It omits the documents needed to follow the earlier question. Keep the original event attached to the original entity. In this example, the first invoice and terms name Company A, identifier DEMO-A. Subsequent changes are added to the log; they do not replace that entry. Period 1 · E01 / E02 Purchase and question Invoice and terms name Company A, DEMO-A. The SME records its question, delivery evidence and the response received. Period 2 · E03 New brand presentation The group website names Company B as the current service contact. The log preserves the earlier terms and asks when, and through what document, the role changed. Period 3 · E04 Subsidiary sale A disposal announcement removes Company A from the current group picture. The log records what was sold, completion date, announcement date and the continuing company identifier. Period 4 · E05 Different results presentation Continuing operations and adjusted results emphasise the retained business. The log also keeps discontinued operations, reported totals and the reconciliation notes. Period 5 · E06 / E07 Reporting calendar revised An announced year-end change is later revised. Both announcements stay visible, together with the period covered and the actual reporting deadline. Period 6 · E08 New adviser and leadership Effective and announcement dates are logged. The earlier question remains linked to its documents and the organisation asked to answer it. The history still asks a precise question. Company A was named at the transaction date. Which records explain the subsequent changes, and who now holds the records needed to answer that transaction question? Preserve the original event through later changes The original invoice and company identifier link to a versioned event log. The log connects separately to later names and roles, sales and reporting changes, and the outstanding question. Later records are added rather than overwriting the original. Original event + entity Versioned event log Names and roles Sales and reporting Outstanding question", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [ "Preserve the original event through later changes The original invoice and company identifier link to a versioned event log. The log connects separately to later names and roles, sales and reporting changes, and the outstanding question. Later records are added rather than overwriting the original. Original event + entity Versioned event log Names and roles Sales and reporting Outstanding question" ] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#narrative-gaps", "heading": "Signs that the explanation needs a closer look.", "text": "Signs that the explanation needs a closer look. Look for the missing connection between an earlier event and a later answer. What the reader encounters What becomes harder to follow Record or question that restores the link “We no longer operate that business.” The reply describes the current position while the question concerns an earlier period. Who operated it on the transaction date? Keep the old terms, invoice and disposal record together. A brand is moved, renamed or merged. A familiar trading name can conceal a change in the company named for a role. Compare company identifiers, dated terms and the document making any role or contract change. “Simplification”, “integration” or a new group structure. The latest organisation chart may omit the subsidiary involved in the earlier event. Retain before-and-after subsidiary lists, ownership dates and the stated scope of the reorganisation. A positive adjusted result beside a reported loss. Different metrics or business scopes are treated as if they measure the same thing. Reconcile reported and adjusted figures, total and continuing operations, impairments, disposal adjustments and cash movements. A reporting period changes more than once. Readers lose track of the months covered, comparatives and the next due date. Record every version; separate period end, filing deadline and results announcement date. A new adviser or leadership team is presented as a fresh start. Earlier representations and outstanding matters disappear from the current explanation. Keep effective dates, appointment announcements, previous statements and the records of any continuing issue. An audit-exemption label is treated as the end of the trail. The linked parent accounts, members’ agreement and guarantee are overlooked. Open the associated filings and identify the relevant parent, period and guarantee. The concern to test is the omission: does the response explain the historical event, or only present the current company? A new narrative can change what is prominent. Preserved source documents let a reader recover what was left out.", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#nomad-change", "heading": "NOMAD changes: follow the handover and the dates.", "text": "NOMAD changes: follow the handover and the dates. A nominated adviser, or NOMAD, advises an AIM company on its AIM responsibilities. A change belongs in the chronology because the adviser and its appointment date are part of the company’s disclosure arrangements. The AIM rules require notification of adviser changes. For taking over an existing company, the nominated-adviser rules normally expect the incoming adviser to understand major developments and contact the outgoing adviser about its experience. Record the outgoing and incoming firm, announcement date and effective date. Identify whether the nearby event is a results announcement, financial year-end or filing deadline. Compare preceding announcements with subsequent explanations. What older matters continue across the appointment? Separate a disclosed reason for the change from a reason you are trying to establish. The useful question: what continuity of the earlier record is visible after the handover? LSE · AIM Rules for Companies · LSE · AIM Rules for Nominated Advisers", "sources": [ "https://www.londonstockexchange.com/content/dam/lse/en_us/documents/rules-and-regulations/aim-rules-for-companies.pdf", "https://www.londonstockexchange.com/content/dam/lse/en_us/documents/rules-and-regulations/aim-rules-for-nominated-advisers.pdf" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#off-book-trades", "heading": "Off-book trades: read the market record accurately.", "text": "Off-book trades: read the market record accurately. Here, “book” means the exchange’s order book. An off-book trade is executed outside that order book and may still be reported to the exchange. This is different from omitting a transaction from a company’s financial accounts. On a quote-driven service, transactions agreed through market makers can form much of the visible activity. SETSqx combines market-maker quotations with periodic order-book auctions. The trading service therefore matters when interpreting a run of trade flags. A change worth documenting: an observable change in execution mix, volume or reporting timing. Log it with the data coverage and surrounding public announcements, then ask what market records explain it. Identify the security, trading service, venue and exact trade-type codes. Keep execution time and publication time separate; note delayed reports, corrections and cancellations. Count the complete period being claimed. A latest-trades screen establishes only the displayed sample. Retain prices, sizes and flags. Buyer/seller identity and a company’s reason for restructuring require different records. Ask: what changed in the trading pattern, against which baseline, and how complete is the record? LSE · SETSqx trading service", "sources": [ "https://www.londonstockexchange.com/en/markets-products/asset-classes/shares/setsqx-and-seaq" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#audit-and-identity", "heading": "Follow obligations through the structure.", "text": "Follow obligations through the structure. A name change leaves the company’s identifier available to follow. A sale raises another set of questions: was it a sale of shares, particular assets or a business undertaking, and which entity was named in the original transaction? For a subsidiary audit exemption, inspect the statutory basis and the associated documents. Under the section 479A route, these include the members’ agreement, parent consolidated accounts with an auditor’s report, and the parent guarantee. The guarantee can be a particularly important record when tracing outstanding obligations. Keep the financial meanings separate: an impairment changes an asset’s carrying value; a disposal result measures the accounting outcome of a sale; a debt balance and an unresolved claim are different records. Follow the relevant note rather than treating every negative figure as the same loss. Companies House · accounts and subsidiary exemptions · Companies Act · effect of a name change", "sources": [ "https://www.gov.uk/government/publications/filing-your-companies-house-accounts/life-of-a-company-part-1-accounts", "https://www.legislation.gov.uk/ukpga/2006/46/section/81" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#keep-event-log", "heading": "Build a record that survives a new narrative.", "text": "Build a record that survives a new narrative. Keep Why it matters Stable event ID and company identifier The same event remains findable after names, roles or ownership change. Event date, publication date and access date A later filing is not mistaken for the date the underlying event happened. Original document, public URL and document reference The source can be read alongside later summaries. Exact statement and relevant page Readers can compare what was actually said at each stage. Later version linked to the earlier version An updated announcement adds history rather than overwriting it. Question, response and unresolved point The question remains visible through a sale, a new contact or an adviser change. Keep public research and private correspondence in separate collections. An access-controlled original can support a general educational example without publishing someone’s personal information. Preserve the sequence, then ask for the bridge: which document connects the original event to the explanation being given now?", "sources": [], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] }, { "id": "https://filmpass.nsstudio.uk/article-03-corporate-changes-records.html#corporate-reading", "heading": "Read the public records alongside the illustration.", "text": "Read the public records alongside the illustration. The source documents below illustrate disposals, reporting changes and the distinction between original events and later presentation. They are kept separate from the invented chronology above. Issuer results centre · compare successive annual and interim reports Issuer’s 2025 results held in the FCA National Storage Mechanism · reported and adjusted results Subsidiary filing history · period changes and linked audit-exemption documents Public corporate-change dates already in the research directory Company names and identifiers · read the original filings Educational example and public-source review: 2 November 2026. Current rules and live register entries can change; retain the version used for each dated observation.", "sources": [ "https://www.themission.co.uk/investors/results-centre/", "https://data.fca.org.uk/artefacts/NSM/RNS/61890f2f-0595-4656-9319-8433aeb41f9a.html", "https://find-and-update.company-information.service.gov.uk/company/09975027/filing-history" ], "interpretation": "Educational explanation; consult the visible qualifications and original source.", "diagrams": [] } ] } ] }