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.
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.
On this page
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.
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.
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.
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
Purpose & member relationship
Evidence: notice, terms, controller decision and service records.
Processing & instructions
Evidence: agreement, role for each activity, subprocessor list and response chain.
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.
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.
Example invoice INV-014
£20 billed by Entity A.
Local reference: order_demo_014 → charge_demo_014.
Example settlement SET-08
Net or converted settlement needs its own reconciliation.
Supporting ledger: source charge, fees, exchange rate, transfer and payout references.
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 →
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 →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