A partner that decides for itself is a GDPR controller, whatever the contract says

If your product shows a lender's loan offers in its dashboard, sells an insurer's cover at checkout, or lets a reseller sign customers up for you, that partner probably got your standard DPA, because that is the contract template the team already had. Your privacy policy then lists the partner with your other vendors. But a partner that uses your customers' data for its own purposes, such as a lender deciding who gets a loan, is not your processor, whatever the contract calls it, and both the contract and the privacy policy describe it wrongly. On 7 October 2026 Italy's data protection authority, the Garante, fined Poste Italiane 48,000 euros and Deutsche Bank 33,000 euros over privacy notices that described their loan partnership in those wrong roles 1 2.

The case started with a single complaint. A Poste employee who had applied for one of the loans objected that the bank's refusal, with her income and debts, was visible to colleagues on the shared loan portal 1. It ended with both companies' documents examined, both fined, and Deutsche Bank ordered to rewrite its privacy policy within six months 2.

Why is a partner that decides for itself not your processor?

Because the GDPR assigns roles by what each company does. A processor handles personal data "on behalf of the controller", and the controller is the company that "determines the purposes and means": why the data is used and how 3. The EDPB, the board where the EU's data protection authorities agree common positions, says a company's role "must in principle be determined by its actual activities in a specific situation, rather than upon the formal designation" in a contract, since otherwise companies could "allocate responsibility as they see fit" 4.

The Italian case shows the test applied to a sales partnership. Poste Italiane, Italy's postal operator, sells personal loans at its post office counters, and its product page names four banks that grant them, Deutsche Bank among them. Staff enter each application on a portal the bank provides, and the bank decides whether to lend. The two decisions 1 2 set out how that was papered and what the Garante made of it:

• The paperwork. Under the companies' agreement, the bank was Poste's processor for the details Poste sent, and Poste was the bank's processor for the bank's answers. Deutsche Bank's privacy policy called Poste an "external data processor".
• The bank decides alone. Deutsche Bank runs the credit check and decides whether to lend. Italy's Consolidated Law on Banking makes assessing the borrower's creditworthiness the lender's own duty.
• Poste has its own purposes. It has its own contract with the customer, and its relationship with the customer continues after a refusal: it can offer a loan from another bank.

Neither company was following the other's instructions, so the Garante found two independent controllers, each deciding its own purposes alone, and fined both for breaking Article 5(1)(a), which requires data to be handled fairly and transparently, and Article 13, which lists what a company must tell people when it collects their data 3.

The EDPB's own example has the same shape: a travel agency sends a customer's details to an airline and a hotel, and "each of the actors processes the data for carrying out their own activities and using their own means", which makes them "three different data controllers" 4. Working in a shared tool does not change that on its own: Poste's staff used the bank's portal, and the Garante still found two independent controllers. I wrote about sorting ordinary suppliers into these groups in the post on which vendors need a DPA.

What does the privacy policy have to say about the partner?

It has to tell customers who receives their data, and that the partner uses it for its own purposes. Article 13(1)(e) requires "the recipients or categories of recipients of the personal data" 3, so a category such as "lending partners" is allowed. The Garante's order to Deutsche Bank adds what that category has to convey for a partner that decides for itself: the policy has to reflect that the partner is a controller in its own right 2. According to the EDPB's English summary of the case 5, Poste's policy did not clearly explain what happens to the data while it sells and arranges the loan, including what goes to the bank and what comes back.

Poste also argued that it kept its privacy policy short on purpose, to spare customers "privacy fatigue". The Garante rejected that: "concision and completeness are not alternative requirements", and a policy is adequate only if "both are respected" (my translation from Italian) 1. Article 12(1) asks for concise, plain information 3, and the same text must still contain everything Article 13 lists. A short privacy policy is good, but it cannot leave the partner out.

The original complaint carries a lesson for any shared screen. The Garante made no finding on what the employee's colleagues could see, but Deutsche Bank told it that it had instructed staff to keep credit information and personal details out of free-text notes 2.

Is a SaaS platform showing financing offers in the same position?

It depends on how the platform integrates the offers. Stripe offers SaaS platforms Capital for platforms, which shows loan offers to the platform's business customers, including in Germany, France and the UK. Business customers are still people under the GDPR here: the applicant is an owner or director, and in Germany, France and the UK directors give a personal guarantee. The documentation says "Stripe and its financial partners manage eligibility, underwriting, pricing, funding, servicing, and collections". The Capital section of Stripe's privacy center names Stripe as the data controller and says "we may also share and receive information about you with your Platform".

With Stripe-branded offers, Stripe prequalifies accounts from data it already holds and shows the offer in its own Dashboard, so the platform sends nothing new. With an embedded component or the API, the platform puts the offer inside its own product, may send its own data and receives information back. In that second case the lender decides the credit, as Deutsche Bank did, and the platform owns the customer relationship and chooses to present the offer, as Poste did. I would treat the platform as a controller for what it shows, sends and receives. Stripe's privacy notice covers what Stripe does and cannot describe the platform's side, so in my reading the platform's own privacy policy should say that it presents financing offers from Stripe and its lending partners, that Stripe uses the data for its own purposes, and what comes back.

The same shape appears in other places:

• Insurance or warranty offers at checkout, where the insurer prices and accepts the cover.
• Resellers and referral partners who sign customers up for a product and keep their own relationship with them.
• Marketplaces that pass a buyer's order to an independent seller, who fulfils it and keeps its own customer record.

What should you check if your product passes customers to a partner?

If your product passes customers to a company that decides something about them, or takes customers from one, check that your contract and your privacy policy describe that partner in its real role. Otherwise one complaint can lead to an investigation of both companies' documents, a fine for each, and an order to rewrite yours.

• List every partner flow. Include financing and insurance offers, resellers, referral programmes and marketplace sellers. Leave out ordinary suppliers such as a payroll provider that only follows your instructions: those are usually processors.
• Ask whose purpose each flow serves. If the partner uses the data for its own purposes, such as its own lending decision, its own customer record or its own legal duties, it is a controller for that data, whatever your agreement calls it. A vendor that approves or prices on your rules and for your purposes, such as a scoring service you configure, stays your processor.
• Match the contract to that answer. If each company pursues its own purposes, replace the processing agreement with a clause saying each is a separate controller, and how each passes on requests from customers that concern the other. Only if you share a common purpose and agree the essential means together are you joint controllers (companies that decide together), and then Article 26 requires an arrangement that sets out who does what 3.
• Describe the partner in your privacy policy. Say what you send (for example the applicant's name and the business's payment history), what comes back (an offer, an approval or a refusal), and that the partner uses the data for its own purposes. Naming the partner and linking its privacy policy is clearer than a category. Take it off your sub-processor list, since a separate controller is not one. Sending the data needs a lawful basis too; when the customer applies for the partner's offer, that is usually Article 6(1)(b), steps taken at their request before a contract 3, the same basis the Garante found each company relying on 1.
• Limit what partner staff see. Show them the fields their job needs, and keep free-text notes out of shared screens.

Partner integrations usually arrive as ordinary code changes, such as a new offer component or a new API call. Lawcel, a compliance tool that reads pull requests and reports which of your legal documents each change affects, can point to the privacy policy when a change like that lands. Deciding whether the new partner is your processor or a controller in its own right is still your team's call.