Executive Summary
- The hypothetical bank should begin with generation inside its controlled EU environment and exclude supplier reuse from the initial permission. This preserves control over customer records, trained components and disclosures while the bank establishes lawful processing, confidentiality permissions and adequate safeguards. EU hosting alone does not resolve Brazilian support access. (Regulation (EU) 2016/679, General Data Protection Regulation (GDPR), Arts 5, 6, 28 and 32.)
- The EU’s Brazil adequacy decision permits covered transfers to Brazilian controllers and processors subject to Brazil’s General Personal Data Protection Law (LGPD). Remote access by the separate Brazilian supplier can constitute a transfer even when records remain on EU servers. Adequacy supplies the transfer mechanism; the bank must separately justify the processing and disclosure. Brazil’s outbound rules also govern qualifying return or onward transfers. (Commission Implementing Decision (EU) 2026/179, Art 1; GDPR, Arts 44–45; ANPD Resolution 32/2026, Arts 1–2.)
- The bank determines the purpose of its fraud testing. A supplier acting on documented bank instructions can process on its behalf. Supplier development for other customers requires a separate purpose and role assessment, including the bank’s authority to disclose the information. A contractual improvement licence cannot establish that authority. (GDPR, Arts 4(7)–(8), 5(1)(b), 6(4) and 28(10).)
- Artificial records and trained weights require separate anonymity assessments. The relevant questions include whether a person can be singled out, linked to other information or exposed through inference or extraction, using reasonably likely means. Removing names or passing selected technical tests does not establish anonymity for every recipient. (GDPR, recital 26; EDPB Opinion 28/2024, paras 38–48.)
- Irish customer confidentiality, the bank’s own confidential information and the Digital Operational Resilience Act (DORA) remain material to access and release. The bank must assess whether the service supports a critical or important function and apply the corresponding contract requirements. That classification differs from formal designation of the supplier as a critical ICT third-party provider. (Regulation (EU) 2022/2554, Arts 3(22)–(23), 28, 30 and 31.)
- If an output reveals an identifiable customer’s transaction pattern, suspend the affected release, contain access and reassess the artefacts and recipients. A security breach requires the applicable notification assessment; a defect discovered during authorised testing does not automatically satisfy that definition. Responsibility follows the parties’ actual activities and purposes. (GDPR, Arts 4(12), 28(10) and 33–34.)
The bank’s records and the artefacts created from them
The bank should control the first deployment and the information allowed to leave it. The supplier’s software examines real transaction records and creates new records intended to preserve useful statistical patterns. Those artificial records may allow testing without repeatedly exposing the original dataset. The legal assessment must follow each artefact through collection, training, generation, support and release.
Real customer records remain personal data where they relate to identifiable individuals. Replacing an account number with a token creates pseudonymised inputs when additional information can reconnect the records to customers. Keeping the key with the bank reduces exposure, but transaction combinations can provide another route to identification. Synthetic outputs require their own assessment because a generated record may reproduce or reveal information about a real person. Trained weights, which encode what the model learned, can also permit extraction of personal information. Diagnostic logs and support prompts can retain source records, generated examples, identifiers or error traces. The bank should therefore inventory all five categories and assess their actual content and access conditions. (GDPR, Arts 4(1), 4(5) and 5(1)(c); recital 26; EDPB Opinion 28/2024, paras 31–48.)
The bank is the controller for its defined testing purpose because it determines why customer records are used and the essential means. The supplier is a processor where it operates the service or supports it using personal data on the bank’s documented instructions. A software licence alone does not make a supplier a processor if the supplier performs no processing of personal data. The contract should match the operations actually undertaken, including diagnostics and remote support. (GDPR, Arts 4(7)–(8) and 28(3).)
Supplier use for its own reusable product creates a different question. If the supplier determines that purpose and its essential means, it acts as controller for that processing. Joint controllership requires actual joint determination; commercial cooperation alone does not establish it. A processor that determines its own purposes and means becomes a controller for that processing under Article 28(10). The parties should specify the role for each activity instead of assigning one label to the entire relationship. (GDPR, Arts 4(7), 26 and 28(10).)
A lawful testing purpose and a separate improvement purpose
The bank must establish a lawful basis before the software learns from customer records. Fraud prevention can be a legitimate interest, but Article 6(1)(f) also requires necessity and a balance against affected people’s interests and rights. The bank should define the fraud-testing objective, explain why the selected records and detail are necessary, and compare less intrusive alternatives. The assessment should address unexpected uses, sensitive transaction patterns and the consequences of faulty or exposed outputs. GDPR recital 47 recognises fraud prevention as a legitimate interest to the extent processing is strictly necessary. It does not authorise every proposed training dataset.
A legal-obligation basis requires an identified duty and processing necessary to comply with it. A general reference to financial regulation leaves those elements unestablished. Article 6(1)(b) concerns a contract with the data subject; the bank’s supply contract with the Brazilian company cannot itself justify processing customer records on that basis. (GDPR, Arts 6(1)(b)–(c), 6(1)(f) and 6(3).)
Testing may be a further use of records collected to provide banking services. Where the bank relies on compatibility with the original purpose, Article 6(4) requires examination of the connection between purposes, the collection context and customer relationship, the nature of the data, possible consequences, and safeguards. Fraud testing closely connected with protecting customer accounts has a stronger connection than development of a supplier’s product for unrelated customers. That distinction still requires assessment of the particular records and proposed operations. Compatible further processing can rely on the original lawful basis. An incompatible use requires valid consent covering it or an applicable Union or Member State law meeting Article 6(4)’s conditions. A new commercial objective or a rewritten privacy notice does not establish compatibility. (GDPR, Art 6(4) and recital 50.)
The supplier’s strongest argument is that improving fraud detection can benefit banks and customers, and that a restricted dataset may make its use proportionate. That argument deserves a documented necessity and balancing assessment where legitimate interests is available. It does not establish the bank’s separate permission to disclose customer information. The bank must assess its disclosure purpose, compatibility, confidentiality and transparency; the supplier must assess its own collection and use. A bank approval clause records a commercial decision, while each controller remains responsible for its lawful processing. (GDPR, Arts 5(2), 6, 13(3), 14(4) and 24; EDPB Opinion 28/2024, paras 61–95.)
Payment records can reveal health, religion or other Article 9 information. Where the processing involves those categories, an Article 9(2) condition is required in addition to an Article 6 basis. Criminal-offence data require the separate Article 10 assessment. Excluding unnecessary sensitive fields and rare revealing combinations should precede training. Calling the work statistical testing does not by itself establish the research or statistical safeguards and exceptions in Article 89. (GDPR, Arts 5(1)(c), 9, 10 and 89.)
Brazilian processing requires its own LGPD analysis. Reliance on legitimate interests under Articles 7(IX) and 10 entails a legitimate purpose, necessity, transparency and protection of the data subject’s rights. Sensitive data falls under Article 11, which contains a narrower fraud-prevention condition concerned with identification and authentication in electronic registration systems. The supplier cannot extend that condition to all fraud-model training merely by describing its product as antifraud software. For sensitive health data, Article 11, paragraph 4, also prohibits sharing between controllers for economic advantage outside its specified health-service exceptions. Supplier reuse must be assessed against that restriction. (Lei 13.709/2018, Arts 3, 6, 7 and 10; Art 11(II)(g) and § 4.)
What adequacy permits between the EU and Brazil
The bank can use the EU’s adequacy route for a covered transfer to the Brazilian supplier. Commission Implementing Decision (EU) 2026/179 of 26 January 2026 recognises adequate protection for personal data transferred to controllers and processors in Brazil that are subject to the LGPD. It was published on 28 January 2026. The decision supplies Article 45 protection for that defined class of recipients, without requiring an Article 46 transfer safeguard for the same covered flow. It preserves supervisory powers and provides for monitoring, review, suspension or repeal. (Decision 2026/179, Arts 1–3; GDPR, Arts 44–45.)
The bank should identify the receiving legal entity and why its processing falls within the LGPD. The decision does not cover processing outside that defined scope or establish a lawful purpose for access. Ordinary commercial fraud testing should be analysed under the GDPR and LGPD rules applicable to the parties. A label referring to crime prevention does not convert the arrangement into a competent authority’s law-enforcement processing.
Remote access matters independently of server location. A bank subject to the GDPR that makes personal data available to a separate Brazilian supplier can make a Chapter V transfer through remote support. In its final, nonbinding Guidelines 05/2021, the European Data Protection Board (EDPB) interprets Chapter V to include this support access. Its coordinated supervisory interpretation informs the bank’s application of those transfer rules. Keeping storage in Ireland or another EU Member State does not remove the disclosure to the Brazilian entity. Support limited to information that is genuinely anonymous for the relevant processing presents a different transfer question. (EDPB Guidelines 05/2021, version 2, paras 9 and 16, and Example 11.)
The Brazilian supplier’s direct territorial exposure to the GDPR also requires its own Article 3 assessment. Serving an EU bank does not automatically establish an EU establishment, an offer to EU data subjects or monitoring within Article 3(2). The bank’s GDPR duties and the processing contract remain applicable to the bank’s arrangement regardless of that separate assessment. Brazilian operations can engage the LGPD through processing in Brazil. (GDPR, Arts 3 and 28; LGPD, Arts 3–4.)
Brazil has separately recognised adequate protection for transfers to the EU, the three EEA EFTA states and the specified EU institutions, bodies, offices and agencies. ANPD Resolution 32 of 26 January 2026 took effect on publication on 27 January 2026. Its scope excludes processing exclusively for the listed public-security, defence, state-security and criminal-investigation purposes. The supplier must still identify a lawful purpose and an applicable LGPD basis for the Brazilian processing. (ANPD Resolution 32/2026, Arts 1–2 and 6; LGPD, Arts 7, 11 and 33; ANPD Resolution 19/2024, Annex I, Art 9.)
Returning EU-origin information from Brazil is not automatically exempt from the LGPD. The foreign-data return exception in the ANPD transfer regulation requires return exclusively to the origin country or international organisation, adequate protection there, application of its law or rules to the processing and an express exception in the adequacy decision. Resolution 32 contains no such exception. Mere transit without communication or sharing with a Brazilian processing agent has a separate exception. The parties should map the actual return flow and apply the relevant Brazilian requirements. They must also assess any onward disclosure to a cloud, model or support provider in another country. Neither adequacy decision grants permission for every subsequent destination. (ANPD Resolution 19/2024, Annex I, Arts 4–9, particularly Art 8, § 1(I)–(II); Resolution 32/2026, Arts 1–2 and 5.)
If a particular flow falls outside adequacy, the parties need another valid route. GDPR Article 46 safeguards require the applicable conditions to be satisfied; Article 49 derogations have their own restricted conditions. Brazilian transfers may use another mechanism under LGPD Article 33 and the ANPD regulation, including its standard contractual clauses where appropriate. An EU transfer document does not automatically satisfy Brazil’s separate clause requirements. These alternatives should be settled before personal access begins. (GDPR, Arts 46 and 49; LGPD, Art 33; ANPD Resolution 19/2024, Annex I, Arts 15–16.)
Irish confidentiality and the bank’s strongest objection
The bank should establish confidentiality permission before the supplier accesses customer affairs or receives a reusable artefact. In its Irish Nationwide Building Society inquiry, the Central Bank treated banking information as confidential, recognised duties extending to recipients, and explained that the duty is not absolute. It found pseudonyms and redaction impracticable for protecting customers in the particular loan hearings. This administrative determination applied Irish confidentiality law in that procedural setting. Its treatment of transaction details supports careful examination of what a generated pattern can disclose. (Central Bank of Ireland, INBS Inquiry, Module 1, Decision on whether to conduct hearing of evidence in public or private, 2 July 2020, paras 12–16 and 19–21.)
The bank should examine its customer terms, the scope of any permission and the information disclosed to each recipient. Confidential support for the bank’s testing and use for a supplier’s wider product have different purposes and audiences. A finding that an output is anonymous under data-protection law leaves separate questions about customer banking affairs, the bank’s confidential methods and agreed use restrictions. Genuine anonymity does not establish that every customer-confidentiality duty attaches to an output either; the content, circumstances and applicable permission determine that assessment.
The bank’s strongest objection is that the supplier proposes to create a reusable asset whose later recipients, combinations and extraction methods the bank cannot sufficiently control. The bank may then be unable to justify customer disclosure or remedy a release that exposes banking information. A broad clause assigning weights or improvements to the supplier would leave that objection unresolved.
The precise initial design change is to remove the general reuse permission. The contract should allow defined generation, internal bank testing and specified support, with no automatic export of weights, samples or logs for supplier development. Any later reuse should identify the exact artefact, purpose, recipients, access conditions and evidence supporting release. Bank approval should follow the privacy, confidentiality and rights assessments; it cannot replace them. This is a proposed contractual allocation for the first deployment.
DORA applies to the service and its dependencies
The Irish bank must assess DORA before entering the service arrangement. Regulation (EU) 2022/2554 applies to credit institutions from 17 January 2025. Its definition of information and communication technology (ICT) services covers relevant digital and data services provided on an ongoing basis. Recurring generation, maintenance or support can therefore fall within it even where the bank hosts the software. A genuinely one-off supply requires examination of its actual service elements. The bank remains responsible for meeting its obligations when it uses a provider. (DORA, Arts 2(1)(a), 3(18)–(21), 28(1) and 64.)
Criticality depends on the function supported and the effect of disruption or defective performance. A replaceable experimental generator, isolated from production decisions and necessary controls, may support no critical or important function. If the bank depends on its tests to maintain effective fraud controls, failure could materially impair financial performance, continuity or compliance with authorisation or financial-services obligations. The bank should document dependencies, replacement time and the consequences of erroneous test results. The word fraud alone does not settle this classification. (DORA, Arts 3(22) and 28(4).)
For every covered ICT arrangement, the bank must undertake the relevant precontract assessment and maintain its register of information. The written contract must address the service and service levels, service and data locations, security, confidentiality, data access, recovery and return, incident assistance, cooperation with authorities and termination. It must specify whether subcontracting ICT services supporting a critical or important function, or material parts of them, is permitted and on what conditions. DORA expressly addresses personal and non-personal data. An anonymous-output finding therefore does not remove these contract duties. (DORA, Arts 28(3)–(5) and 30(1)–(2).)
Services supporting a critical or important function require the additional Article 30(3) terms, including detailed service levels, continuity measures, monitoring, access and audit rights, and a suitable transition period. The bank must also plan an orderly exit. Its assessment of subcontracting and location risk should include every material cloud or model dependency. Trade-secret protections in an audit procedure should preserve the access needed by the bank and its supervisors. (DORA, Arts 28(6)–(8), 29 and 30(3); Commission Delegated Regulation (EU) 2024/1773, Arts 3–10.)
The recommended contract should identify the cloud, model and support subcontractors eligible to handle the service or its artefacts. It should require advance notice of material changes, a defined period for bank approval or objection, continued supplier responsibility and termination rights for breaches of agreed change controls. These proposed protections must operate alongside the applicable DORA and GDPR requirements. For subcontracting of ICT services supporting critical or important functions, or material parts thereof, Commission Delegated Regulation (EU) 2025/532, Articles 3–6, requires due diligence and contractual controls covering monitoring, equivalent access and audit rights, material changes and termination rights.
The bank must notify its competent authority in a timely manner of planned arrangements supporting critical or important functions, and of relevant changes in classification. The Central Bank’s 2021 Outsourcing Guidance supplies supervisory expectations alongside applicable legislation; its notification provisions expressly distinguish notification from a general pre-approval process. The competent supervisory route must reflect the bank’s status, including applicable ECB responsibilities. (DORA, Arts 28(3) and 46(a); Central Bank of Ireland, Cross-Industry Guidance on Outsourcing, December 2021, Part A, sections 3–5, and section 10.1.1, footnote 30.)
A critical or important bank function and a designated critical ICT provider are separate legal classifications. Designation by the European Supervisory Authorities under Article 31 follows its own criteria and procedure. The additional rule for a designated third-country provider to establish an EU subsidiary does not apply merely because this supplier is Brazilian. (DORA, Arts 3(23) and 31(1)–(2), (12).)
Evidence for an anonymity and release decision
The bank should assess each proposed output and model version in its intended release context. GDPR recital 26 asks whether identification is possible through means reasonably likely to be used, taking account of cost, time, available technology and developments. The assessment concerns the controller and other persons capable of identification. It requires more than checking that generated rows have no customer-name column. Processing customer records to create an anonymous artefact also requires a lawful basis; the later output’s status cannot supply that earlier permission. (GDPR, Arts 4(2) and 6.)
In EDPS v Single Resolution Board, the Court of Justice recognised that safeguards can affect whether pseudonymised information is personal for a particular recipient. Relevant capabilities include obtaining additional information and cross-checking it. An assessment for one recipient does not settle a later recipient’s position. The Court also preserved the controller’s collection-time transparency duties by assessing those duties from the controller’s perspective. The bank should therefore retain its responsibilities over identifiable source records and assess each proposed recipient’s actual means separately. (Case C-413/23 P, EDPS v SRB, EU:C:2025:645, paras 52, 75–89 and 99–113.) For a supplier acting as the bank’s processor, the EDPB’s draft anonymisation guidelines assess personal-data status from the bank’s perspective, even if the supplier cannot itself identify customers. This remains nonbinding consultation guidance. (EDPB Guidelines 02/2026, version 1.0, para 15.)
The EDPB’s adopted Opinion 28/2024 offers nonbinding guidance for consistent supervisory application of the GDPR to AI models. The Board calls for a case-specific assessment of identification and extraction risk. That assessment includes singling out a person, linking information about them, inferring attributes and obtaining information through queries or model access. Direct access to weights can permit attacks that an application interface prevents. The Board treats testing and safeguards as evidence to evaluate, with their limitations, and specifies no universal anonymity test score. (EDPB Opinion 28/2024, paras 34 and 38–58.)
The proposed release procedure should record the dataset, model and software versions, the purpose and the intended recipients. Technical reviewers should examine duplicate and near-duplicate records, rare transaction combinations, inference of personal attributes and extraction of training information. Membership-inference tests should examine whether an attacker can establish that a person’s records were used for training. Testing should consider realistic auxiliary information, repeated queries, combinations of multiple releases and access to weights. If the supplier uses differential privacy, the record should explain its parameters, assumptions, implementation and effect on useful testing. These are proposed evidence requirements; the legal assessment remains tied to reasonably likely identification in the actual context.
The bank should assign technical testing to qualified reviewers and retain an accountable release decision, informed by its legal advisers and data protection officer. The decision should state residual risk, permitted recipients, controls, expiry or review triggers and withdrawal arrangements. A release of a dataset should not silently approve the corresponding weights, checkpoints or logs. New recipients, additional data, changed access or a successful attack should trigger reassessment. The LGPD has its own anonymity test, including actual reversal using exclusively the means of the agent responsible for anonymisation, or possible reversal with reasonable efforts measured by cost, time and available technology. A Brazilian release requires that assessment where the LGPD applies. (GDPR, Arts 5(2), 24–25 and 32; LGPD, Arts 5(III), 5(XI) and 12.)
The release specification should also address applicable AI Act marking duties. If the generator produces synthetic text within Article 50(2), its provider must ensure the required machine-readable marking and detectability, subject to the provision’s technical qualifications and exceptions. The contents and use of an output matter; tabular delivery alone does not establish an exemption. Article 50 applies from 2 August 2026. Systems placed on the market before that date have until 2 December 2026 to comply with Article 50(2). The supplier must establish the system’s first EU market-placement date before relying on that transition. (Regulation (EU) 2024/1689, Arts 50(2), 111(4) and 113, as amended by Regulation (EU) 2026/1744.)
Rights in data and trained components
The contract should identify bank inputs and labels, the supplier’s existing software, project datasets, trained weights, documentation and later improvements separately. For each asset, it should specify permitted copying, training, testing, disclosure and retention. The bank needs sufficient use rights to validate results, satisfy supervisory demands and execute an agreed exit. A general ownership statement leaves those operational permissions unclear.
The recommended allocation leaves each party’s pre-existing rights with that party. The supplier should grant the bank continuing rights in the agreed project artefacts for authorised internal testing, supervisory disclosure and migration. Those permissions should cover relevant datasets, trained components and documentation, subject to lawful retention and identified third-party restrictions. The supplier’s rights in improvements should remain subject to the separate prohibition on unapproved reuse of bank information.
Irish copyright can protect qualifying software and original database selection or arrangement. A separate database right depends on qualifying investment and statutory eligibility. Funding development does not necessarily determine authorship or first ownership, and a Brazilian maker’s eligibility for Irish database rights should not be assumed. The parties should establish the chain of rights and effective assignments or licences for the protected assets. (Copyright and Related Rights Act 2000, ss 2(1), 17–18, 21, 23, 120(3) and 321–327.)
Investment in creating materials does not automatically count as investment in obtaining existing materials for database-right purposes. That distinction limits a claim that expensive synthetic generation necessarily creates such a right. The protection of any particular model weights or dataset depends on the applicable legal category and facts. (Case C-762/19, CV-Online Latvia v Melons, EU:C:2021:434, paras 24–27.)
Supplier ownership of qualifying software or improvements cannot authorise unlawful personal-data processing. Qualifying trade secrets also receive protection against use contrary to secrecy or contractual use obligations, subject to the applicable exceptions. The agreement should address third-party model licences, subcontractor terms, confidential bank patterns and restrictions on residual knowledge or feedback. AI due diligence on data and model rights covers the related review of provenance, licensing and dependencies. (GDPR, Arts 5–6 and 28; European Union (Protection of Trade Secrets) Regulations 2018, SI 188/2018, regs 3, 5–6.)
Customer rights and safeguards during testing
The bank should complete its purpose, necessity and risk assessments before using live records. A data protection impact assessment (DPIA) is required where processing is likely to create high risk, including applicable Article 35 triggers and the Irish Data Protection Commission’s mandatory list. Large-scale profiling, linking datasets and reuse for a new purpose can engage those tests. The proposed service should undergo documented screening; a DPIA should precede live use where the assessment identifies the statutory threshold. If high residual risk remains after proposed measures, Article 36 requires prior consultation. (GDPR, Arts 35–36; Data Protection Commission, List of Data Processing Operations which require a Data Protection Impact Assessment, 15 November 2018, items 1, 4–5 and 9.)
Customer information must explain the purposes, recipients, retention and relevant transfers. A further purpose requires the applicable additional notice before that processing. Access, rectification, erasure, restriction and objection duties continue while the information remains personal, with their statutory conditions and exceptions. The bank should use information it legitimately holds to trace relevant records through training sets, logs and affected artefacts. Article 11 does not require extra identification information solely for GDPR compliance where the processing purposes do not or no longer require identification. If a customer supplies information enabling identification, the applicable rights must still be addressed. (GDPR, Arts 11–18, 21 and 28(3)(e).)
A promise to delete the source row is insufficient if personal information remains accessible elsewhere. The parties should assess whether retraining, verified removal of learned personal information, restriction or withdrawal provides an effective response. Article 20 portability concerns qualifying data provided by the individual where automated processing rests on consent or contract. If later deployment makes solely automated decisions with legal or similarly significant effects, Article 22 requires a separate assessment. Generating records for testing does not itself establish that decision-making activity. (GDPR, Arts 17, 20 and 22.)
The retention schedule should distinguish raw inputs, pseudonymisation keys, temporary generation data, checkpoints, logs and approved releases. Keep each for its justified period and implement secure return or deletion at service end, subject to applicable retention duties. Restrict support by role and duration, protect keys separately, log access and prohibit unnecessary copying into tickets or prompts. Subprocessors need the required authorisation and equivalent processing duties. The contract should give the bank evidence and audit access sufficient to verify those controls. (GDPR, Arts 5(1)(c), 5(1)(e), 25, 28(2)–(4) and 32; LGPD, Arts 15–16, 18, 37–39 and 46.)
The associated data maps, lawful-basis records, DPIAs and processor arrangements are addressed in Licentium’s AI data protection preparation. For this deployment, the record should connect those documents to the actual support permissions and the artefacts eligible for release.
A generated output exposes a customer’s transactions
If an output reveals or permits inference of an identifiable customer’s transaction pattern, suspend the affected release and preserve the evidence. The bank and supplier should identify the source of the inference, the affected versions, recipients and customer information. They should restrict access, assess downstream copies and decide whether regeneration, retraining or withdrawal is required. The discovery undermines the relevant anonymity claim and requires reassessment of related artefacts; it does not automatically prove that every version contains personal data.
The incident assessment must distinguish a defect found during authorised testing from a personal-data breach. Under Article 4(12), a breach requires a security failure leading to the specified loss, alteration, destruction, unauthorised disclosure or access. If the supplier is acting as processor, it must notify the bank without undue delay after becoming aware of a personal-data breach. The bank must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to risk people’s rights and freedoms. It must document the breach and assess whether high risk requires communication to affected individuals without undue delay, subject to Article 34’s exceptions. (GDPR, Arts 33–34.)
Brazilian incident duties require a separate assessment where the LGPD applies. Notification depends on possible significant effects on fundamental interests and rights together with at least one listed criterion, which includes financial data. The ordinary deadline for controller communications to the ANPD and affected people is three working days after awareness that the incident affected personal data. The regulation preserves applicable specific-law deadlines for ANPD notification and doubles the relevant periods for qualifying small processing agents. The service agreement should require sufficiently prompt cooperation to meet each applicable deadline. (LGPD, Art 48; ANPD Resolution 15/2024, Annex, Arts 4–6 and 9.)
The bank must also assess DORA’s incident classification and reporting requirements; a GDPR breach does not automatically establish a major ICT-related incident. Where a major ICT-related incident affects clients’ financial interests, the bank must inform those clients without undue delay about the incident and mitigation measures. (DORA, Arts 18–19, particularly Art 19(3).)
Actual conduct determines responsibility. A supplier that used personal artefacts for its own product cannot rely on a processor label for that activity. GDPR compensation requires material or non-material damage resulting from an infringement. A processor is liable where it breaches processor-specific duties or acts outside or contrary to lawful instructions; Article 82(3) permits exoneration on proof of no responsibility for the event. Contractual indemnities may allocate losses between the parties, but cannot remove statutory duties or data subjects’ rights. The agreement should address containment costs, evidence preservation, downstream cooperation, remediation and recovery of the bank’s usable assets. (GDPR, Arts 28(10) and 82(1)–(5); LGPD, Arts 42–44.)
Conditions for offshore processing and commercial reuse
The bank-controlled deployment provides a justified first step because it limits the initial access and release permissions the bank must establish. It should retain source records and keys under bank control, permit only defined support access and prohibit supplier reuse by default. The bank can then approve a particular support session or output through the assessed permissions and controls. The recommendation is a design choice based on this transaction’s risks; the relevant legislation does not impose a general prohibition on Brazilian processing.
Training or generation in Brazil can proceed where the parties establish lawful processing, customer-confidentiality permission, a covered transfer route and credible security, subcontracting, audit and exit arrangements. The bank should assess the entire processing location and dependency chain, including diagnostics and onward access. Those conditions must be satisfied before enabling the offshore activity. A covered adequacy transfer removes the need to establish an alternative transfer safeguard for that flow, while the other duties continue.
Where the service supports a critical or important function, the bank must assess effective enforcement of relevant obligations in Brazil, the applicable insolvency law and constraints on urgent data recovery. The arrangement should make its audit and return rights workable in those circumstances. (DORA, Art 29(2).)
Commercial reuse requires a further decision about the specified artefact and recipient context. Where personal information remains, the parties need lawful processing and disclosure for that purpose, appropriate roles, transparency and transfer arrangements. Where a supported anonymity assessment excludes the applicable data-protection duties for the released information, confidentiality, contractual permissions and any subsisting intellectual property rights still require resolution. The supplier should therefore offer wider reuse only for individually approved datasets or components, with evidence, defined recipients and enforceable withdrawal cooperation. If those conditions cannot be met, the bank’s separately lawful private testing service can continue without that release.