Executive Summary
- Restrict the initial product to document checks, one-to-one verification of a claimed identity and advisory AML assessments. Those functions do not establish an AI Act high-risk classification by themselves. Database identification, sensitive biometric categorisation or creditworthiness scoring require separate analysis. Human review does not remove an otherwise applicable high-risk classification. (Regulation (EU) 2024/1689, Arts. 3(35)–(41), 6; Annex III, points 1 and 5(b).)
- The enacted AI Omnibus changed the timetable. Chapter III, Sections 1–3, generally apply to Annex III high-risk systems from 2 December 2027, excluding Article 6(5). The corresponding Annex I date is 2 August 2028. Existing prohibitions, AI literacy and applicable transparency duties still require attention. (Regulation (EU) 2024/1689, Arts. 4, 5, 50, 113, as amended by Regulation (EU) 2026/1744.)
- The bank normally controls the purposes of KYC processing; the vendor processes data on its instructions. Technical facial matching for unique identification requires an Article 9 condition alongside an Article 6 basis. An AML obligation does not, without the necessary legal conditions, authorize every biometric technique. Formal human approval also cannot disguise a solely automated significant decision. (Regulation (EU) 2016/679 (GDPR), Arts. 4, 6, 9, 22, 28.)
- Processing in India requires a lawful transfer route. EU hosting still leaves a transfer where a separate Indian recipient can access personal data. Standard contractual clauses require an assessment of applicable Indian law, actual access and effective safeguards. Unresolved exposure to incompatible public-authority access prevents that data flow. (GDPR, Arts. 44–46; Decision (EU) 2021/914, Annex, clauses 14–16.)
- The supplier is an ICT third-party service provider when it supplies the ongoing KYC service. Whether it supports a critical or important bank function requires the bank's assessment. Designation as a critical ICT third-party service provider is a separate European Supervisory Authorities process. DORA contract requirements cannot be postponed until the vendor receives that designation. (Regulation (EU) 2022/2554, Arts. 3(19), 3(21)–(22), 28–31.)
- The main DPDP processing provisions remain subject to phased commencement. The bank should assess the operative security, sensitive-data and incident requirements rather than assume the entire DPDP Act already applies. Its future foreign-outsourcing exemption does not displace GDPR. (Digital Personal Data Protection Act 2023, ss. 17(1)(d), 44(2); G.S.R. 843(E), 13 November 2025; Information Technology SPDI Rules 2011, rr. 4, 7–8.)
- Sign a ring-fenced evaluation agreement for synthetic or genuinely anonymous data first. Permit live testing only after the data, biometric, transfer, security and bank-validation conditions are met. A production contract should preserve bank decisions and require demonstrable audit, incident, subcontractor and exit arrangements before activation. (GDPR, Arts. 25, 28, 32, 35–36; DORA, Arts. 28–30; EBA/GL/2022/15, paras. 12–18.)
The product boundary determines AI classification
The vendor should document the intended purpose of each component before pricing a production deployment. A document-reading component may extract text or detect alteration without identifying anyone through biometrics. Conventional software also falls outside the AI Act where it does not satisfy the AI-system definition, including the required inference element. Marketing the entire service as AI does not settle each component's classification. (AI Act, Art. 3(1), (12).)
Article 6(1) separately requires a product or safety-component connection to Annex I legislation and a required third-party conformity assessment. The proposed standalone KYC service does not acquire that classification merely because a bank uses it. Product integration requires a fresh assessment of those cumulative conditions, including the amended safety-component limits and the exclusion for conformity assessment required solely for risks unrelated to health and safety. (AI Act, Arts. 3(14), 6(1)–(1c), Annex I, as amended.)
One-to-one comparison of an applicant's live face with that applicant's identity-document image is biometric verification when its sole purpose is confirming the claimed identity. Annex III expressly excludes that purpose from its remote biometric identification category. Technical facial processing can nevertheless involve GDPR special-category data. The two statutes use different triggers, so the AI Act exclusion cannot authorize the data processing. (AI Act, Art. 3(36), Annex III, point 1(a); GDPR, Arts. 4(14), 9(1).)
Searching an applicant's face against a gallery of customers or suspected fraudsters changes the analysis. Biometric identification compares biometric data with stored biometric data to establish identity. Remote biometric identification requires identification without active involvement, typically at a distance. A one-to-many search loses the sole-verification exclusion, but still needs the positive conditions of an applicable Annex III category. Processing on a server in India does not itself make identification “remote” under that definition. (AI Act, Art. 3(35), (41), Annex III, point 1(a).)
An AML anomaly score is not automatically a credit score. Annex III, point 5(b), covers assessment of natural persons' creditworthiness or establishment of their credit scores, with an exception for financial-fraud detection. If the bank also uses the product to assess creditworthiness, it must assess that intended use separately. A financial-fraud label cannot shelter a component whose actual purpose is credit assessment. (AI Act, Art. 6(2), Annex III, point 5(b).)
Profiling requires a further distinction. Automated evaluation of a person's reliability, behaviour or economic situation can constitute profiling; a score limited to a file's technical authenticity need not evaluate personal aspects. The AI Act's rule that profiling always makes a system high-risk operates within the Annex III perimeter. It does not convert every profiling application into a listed system. (GDPR, Art. 4(4); AI Act, Art. 6(3).)
A provider seeking Article 6(3)'s exception for an Annex III system must establish the absence of significant risk and one of the specified conditions. Those conditions concern narrow procedural, preparatory or otherwise defined auxiliary tasks. The exception is unavailable where the listed system profiles natural persons. The provider must document a qualifying exception and register the system; ordinary human review alone does not establish it. (AI Act, Arts. 6(3)–(4), 49(2).)
The recommended feature specification excludes emotion inference and protected-trait classification. Some biometric categorisation is high-risk; Article 5 prohibits specified sensitive inferences, subject to its defined exceptions. Untargeted scraping to create or expand facial-recognition databases is prohibited. Social scoring requires its stated adverse-treatment conditions, while criminal-offence prediction based solely on profiling or personality traits falls within another prohibition. Document-based AML anomaly detection does not satisfy those prohibitions merely because it concerns financial crime. (AI Act, Art. 5(1)(c)–(g), Annex III, points 1(b)–(c).)
Provider duties, bank duties and the amended timetable
The Indian company is an AI provider if it develops, or has developed, the system and supplies it under its name. The bank is a deployer when it uses the system under its authority. EU market placement or use of the output in the Union can bring a non-EU provider within scope. A purchasing bank becomes an importer only if it satisfies the separate market-placement definition. (AI Act, Arts. 2(1)(a)–(c), 3(3)–(6).)
The parties cannot allocate statutory roles solely through a responsibility schedule. Rebranding a high-risk system, substantially modifying it or changing an intended purpose so that it becomes high-risk can shift provider duties under Article 25. The contract should require approval before model, threshold, intended-purpose or interface changes. It should also secure the documentation and technical assistance needed for any resulting allocation. (AI Act, Art. 25.)
The AI Omnibus is enacted legislation. Regulation (EU) 2026/1744 amended Article 113: Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 for Annex III systems. The corresponding date for Article 6(1) and Annex I systems is 2 August 2028. The general application date remains 2 August 2026, subject to the specific exceptions. A contract should identify the provisions and relevant product category rather than promise compliance against one universal deadline. (AI Act, Art. 113, as amended by Regulation (EU) 2026/1744, Art. 1(40).)
Providers and deployers already have an amended Article 4 obligation to support staff AI literacy. They need not guarantee a particular individual's level. Existing Article 5 prohibitions also remain relevant. Article 50 requires specified disclosures for direct AI interaction and certain other functions, including biometric categorisation and emotion recognition. A backend document checker does not automatically trigger every Article 50 notice; GDPR information duties apply independently. (AI Act, Arts. 4, 5, 50(1), (3), (5), 113; GDPR, Arts. 13–14.)
For a high-risk branch, the procurement schedule should cover risk management, data quality, technical documentation, logging, instructions, human oversight, accuracy and cybersecurity. The provider must address the applicable quality-management, conformity-assessment, declaration, marking, registration and post-market requirements. An Indian high-risk provider must also appoint the required EU authorised representative. These obligations should be allocated against their applicable dates and transition rules. (AI Act, Arts. 9–19, 22, 43, 47–49, 72–73, 111, 113.)
The bank's high-risk deployment duties concern instructed use, competent human oversight, monitoring and the logs under its control. Article 27's fundamental-rights impact assessment is required for its specified deployers and uses. It is not automatically required for every private bank's ordinary KYC tool. Creditworthiness use under Annex III, point 5(b), triggers that assessment; a GDPR impact assessment can supply cross-referenced material without eliminating the distinct requirement. (AI Act, Arts. 26–27, as amended.)
Article 111 contains a transition for certain high-risk systems placed on the market or put into service before the relevant application date. Significant later design changes can remove that protection. A demonstration does not establish that the qualifying market-placement or service event occurred. The recommended contract therefore requires documented lifecycle dates and reassessment of changes, rather than a promise that an early pilot permanently avoids high-risk duties. (AI Act, Arts. 3(9), (11), 111(2), as amended.)
Lawful KYC processing and biometric limits
The bank should remain controller for customer identification, AML assessment and onboarding. The vendor should act as processor for those purposes, with instructions governing collection, matching, scoring and deletion. A vendor that reuses customer images or outputs to train a general product determines a separate purpose and requires a separate role analysis. Independent reuse can make it a controller; joint determination of purposes and essential means can trigger Article 26. Calling that reuse “service improvement” cannot preserve processor status by agreement. (GDPR, Arts. 4(7)–(8), 26, 28(3), (10); EDPB Guidelines 07/2020, version 2.1, Part I.)
The Article 28 schedule must state the processing purpose, duration, data and affected people, with documented instructions and confidentiality. It must address security, assistance with rights and assessments, deletion or return, and audit information. Subprocessors require prior specific or general written authorization, with notice and an opportunity to object under general authorization. The initial processor remains responsible for its subprocessor's obligations. (GDPR, Art. 28(2)–(4).)
The bank's EU establishment brings its processing within GDPR. The Indian supplier's direct territorial position requires its own Article 3 analysis. An EU customer does not, by itself, establish the supplier's EU establishment or its offering or monitoring activities under Article 3(2). Where Article 3(2) applies, the vendor must designate an EU representative in writing unless Article 27(2)'s exception applies. Contractual processor duties and Chapter V transfer protections remain necessary even where the importer is not directly subject to GDPR for those operations. (GDPR, Arts. 3, 27–28, 44; EDPB Guidelines 05/2021, version 2.0, sections 1–2.)
For mandatory AML checks, Article 6(1)(c) must connect to the applicable Union or Member State obligation under Article 6(3). Optional fraud processing may instead require a justified Article 6(1)(f) assessment, including necessity and the person's competing interests. The bank should allocate each processing purpose to its basis. Neither a vendor contract nor the general convenience of remote onboarding establishes necessity for every collected field. (GDPR, Arts. 5(1)(b)–(c), 6(1)(c), (f), 6(3); Directive (EU) 2015/849, Art. 13.)
Technical facial matching used to uniquely identify or confirm an individual ordinarily requires an Article 9 exception. A photograph is not automatically special-category biometric data without the relevant technical processing. Manual document review, biometric templates and any stored matching embeddings therefore need separate treatment. Criminal-conviction or offence data require an Article 10 analysis rather than being treated as ordinary anomaly data. (GDPR, recital 51, Arts. 4(14), 9–10.)
Article 9(2)(g) requires a substantial-public-interest basis in Union or Member State law, proportionality and specified safeguards. A general AML purpose alone does not establish all those elements for facial matching. Explicit consent under Article 9(2)(a) is an alternative only where it is freely given and valid. A genuinely available non-biometric route matters where refusing facial processing would otherwise prevent access to the service. (GDPR, Arts. 7, 9(2)(a), (g), recitals 42–43.)
The amended AI Act's Article 4a permits certain strictly necessary special-category processing for bias detection and correction, with restrictive safeguards. That purpose does not cover routine customer identity matching. The vendor should prohibit bank-data training by default and seek separate authorization for a precisely defined, lawful testing purpose. Representative testing itself must use lawfully obtained data. (AI Act, Art. 4a; GDPR, Arts. 5–6, 9, 28.)
Human decisions, impact assessment and retention
The bank's final decision avoids Article 22's solely automated limb only where staff actually assess the case. The proposed workflow should display source evidence, limitations and intelligible reasons, allow overrides and provide a manual route. Staff must have time and authority to disagree. A required approval click or a score that effectively determines refusal cannot establish independent human assessment. This is a design and operating-evidence condition, not a consequence of the contract's wording. (GDPR, Art. 22(1); Arts. 5(2), 24–25.)
Where a solely automated decision has legal or similarly significant effects, the bank needs an Article 22(2) exception. Contract necessity, authorization by qualifying law and explicit consent each have distinct conditions. Article 22(3) requires safeguards for the contractual-necessity and consent exceptions; Article 22(4) further restricts decisions using special-category data. The recommended deployment avoids automated acceptance or refusal rather than assuming that AML obligations supply an exception. (GDPR, Art. 22(2)–(4).)
Before live processing, the bank should complete a data protection impact assessment where Article 35's threshold is met. Systematic extensive evaluation supporting significant decisions and large-scale special-category processing are express triggers. A small pilot still requires assessment of likely high risk under Article 35(1). If residual high risk remains without sufficient measures, Article 36 requires prior supervisory consultation. The vendor must supply the architecture, access details and test evidence needed for that assessment. (GDPR, Arts. 28(3)(f), 35–36.)
The retention schedule should distinguish the bank's required AML record from disposable face templates, debugging images and model inputs. Directive 2015/849 requires Member States to impose five-year retention of necessary due-diligence records after the relationship ends or an occasional transaction, with regulated possibilities for extension. It does not require the vendor to retain every intermediate biometric artifact for that period. Purpose-specific deletion, restricted legal holds and controlled backup expiry should appear in the processor terms. (Directive (EU) 2015/849, Art. 40; GDPR, Arts. 5(1)(e), 28(3)(g).)
Customer notices should identify purposes, legal bases, recipients, transfers and retention criteria. Access, correction and applicable objection rights need an operational route. Any AML restriction on disclosure must have a valid legal basis; the vendor should not promise unrestricted access to suspicious-activity records. (GDPR, Arts. 13–16, 21, 23; Directive (EU) 2015/849, Arts. 39, 41.)
Processing in India and support access from India
Under the remote-processing model, the bank sends identity data to an Indian processor, which returns checks and scores. India has no Commission adequacy decision. The usual contractual starting point, where the importer falls within the clauses' scope, is Module Two of the 2021 transfer clauses for controller-to-processor transfers. If an EU processor appoints the Indian entity as subprocessor, Module Three addresses that relationship. (GDPR, Arts. 44–46; Commission Implementing Decision (EU) 2021/914, Art. 1, Annex, Modules Two and Three.)
The EU-hosted model requires the same recipient-level analysis. An Indian affiliate viewing identifiable records through remote administration is a separate recipient abroad, even without downloading them. The bank must map the cloud operator, support employer, telemetry recipients, backups and encryption-key holders. An employee abroad within the same legal entity presents a different Chapter V analysis, but access and foreign-law risks still require security measures. (GDPR, Arts. 28, 32, 44; EDPB Guidelines 05/2021, version 2.0, paras. 20–21, examples 7–9 and 11; Annex illustrations 8.1–8.2.)
The parties must assess whether Indian laws and practices prevent the importer from meeting the transfer clauses. That assessment must address the actual data, processing, access powers and available safeguards. Clauses 14–15 require documented assessment, notification and appropriate handling of public-authority requests; clause 16 requires suspension or termination in defined failure circumstances. Ordinary business use should not depend on a blanket Article 49 derogation. (Decision (EU) 2021/914, Annex, clauses 14–16; GDPR, Art. 49.)
Encryption in transit and at rest is insufficient to prevent incompatible public-authority access where the exposed recipient needs plaintext or controls the keys. The EDPB's supplementary-measures recommendations identify that difficulty for cloud processing and remote access. Effective separation can instead prevent Indian staff from obtaining identifiable material through EU-controlled keys, redacted diagnostics and tightly limited support rights. Pseudonymisation only solves the relevant exposure where the importer cannot attribute the data using information reasonably available to it. (EDPB Recommendations 01/2020, version 2.0, Annex 2, use cases 2, 6–7.)
For the initial live phase, the preferred structure is an EU-established processing recipient with identifiable records and keys inaccessible to Indian support. The Indian company would supply the software without receiving customer personal data under that proposed structure. EU hosting alone cannot establish those conditions. If the bank chooses India processing or identifiable India support, it should prohibit activation until the transfer assessment establishes effective protection. Contractual assurances cannot cure a data flow that fails that assessment. (GDPR, Arts. 25, 32, 44–46; Decision (EU) 2021/914, Annex, clauses 14–16.)
DORA classification and the procurement contract
DORA has applied since 17 January 2025 and covers EU credit institutions. An ongoing software, hosting or support service can be an ICT service regardless of whether the bank separately calls it outsourcing. The Indian supplier therefore enters the bank's ICT third-party risk process for the proposed managed service. A DORA ICT third party need not be designated “critical” before the bank owes procurement duties. (DORA, Arts. 2(1)(a), 3(19), (21), 28, 64.)
The bank must assess whether disruption would materially impair financial performance, continuity, regulatory compliance or authorization conditions. A KYC dependency that prevents lawful onboarding may support a critical-or-important-function finding. A segregated test with functioning alternatives may justify a different finding. Neither conclusion follows from the word “KYC” alone. Designation of the vendor as a critical ICT third-party service provider follows the separate Article 31 process. (DORA, Arts. 3(22), 28(4)(a), 31.)
Before contracting, the bank must assess risks, due diligence, conflicts, suitability and relevant supervisory conditions. It must maintain the register of ICT arrangements and inform its competent authority in a timely manner about planned arrangements supporting critical or important functions. DORA does not convert every purchase into a regulatory pre-approval procedure. The bank should assess vendor solvency, operational capability, data locations, common cloud dependencies and practicable alternatives. (DORA, Arts. 28(3)–(5), 29.)
Every covered ICT contract needs a written, accessible allocation of rights and obligations. Article 30(2) requires the service scope, relevant subcontracting conditions, processing locations and advance location-change notice. It also requires data security and recovery arrangements, service levels, incident assistance, authority cooperation, termination provisions and conditions for participation in relevant training. The vendor should price incident assistance in advance rather than reserve unrestricted emergency charges. (DORA, Art. 30(1)–(2).)
For services supporting critical or important functions, Article 30(3) adds detailed service levels, material-development reporting, tested continuity arrangements and security requirements. It also requires relevant threat-led penetration-testing cooperation, enforceable access and audit rights, and an adequate transition period. Certification or pooled assurance may assist assessment, but cannot erase the bank's and authorities' required rights. (DORA, Art. 30(3).)
The incident schedule should require prompt evidence preservation and escalation early enough for the bank's reporting duties. The vendor must notify the bank of a personal-data breach without undue delay; the bank's GDPR deadline is ordinarily 72 hours after awareness, subject to Article 33's risk exception. DORA incident reporting remains the bank's responsibility even where the supplier assists. The parties should agree operational response times separately from those statutory rules. (GDPR, Art. 33(1)–(2); DORA, Arts. 19, 30(2)(f).)
For subcontracting that supports critical or important functions, the schedule must identify permitted activities and relevant providers throughout the material chain. Under Delegated Regulation 2025/532, the bank must assess operational and financial capability, locations, concentration, continuity and obstacles to audit. The contract must address monitoring, flow-down duties, advance material-change notice and approval or non-objection procedures. Unauthorized subcontracting or implementing specified changes despite objection must permit termination. (Commission Delegated Regulation (EU) 2025/532, Arts. 3–6.)
The bank should test exit before becoming dependent on proprietary formats or undocumented scores. The vendor should provide usable records, model-version histories and transition assistance, with agreed costs and a deletion sequence. A second supplier using the same cloud infrastructure may leave concentration risk unchanged. DORA requires the bank to assess substitutability and concentration rather than count vendor names. (DORA, Arts. 28(8), 29, 30(2)(d), 30(3)(f).)
Banking outsourcing and retained AML decisions
The bank must distinguish procurement of ICT from delegation of a business activity. EBA outsourcing guidance tests whether the provider performs a process, service or activity the institution would otherwise undertake. Managed recurring identity checks can meet that test; buying a tool does not settle it. The bank retains responsibility and must apply the relevant national supervisory requirements alongside DORA. (EBA/GL/2019/02, definitions and paras. 26–30, 32, 35.)
The EBA announced final non-ICT third-party-risk guidelines on 18 September 2026. Publication alone does not establish that replacement guidance applies to a particular bank contract. For this software transaction, DORA supplies the binding ICT contract requirements; a separately outsourced manual KYC operation also requires banking-outsourcing analysis. EBA guidelines operate through the supervisory compliance mechanism, unlike directly applicable regulations. (EBA, final third-party-risk guidelines announcement, 18 September 2026; EBA/GL/2019/02, paras. 1–3; DORA, Arts. 28–30.)
The vendor should support the bank's documented pre-implementation assessment. EBA remote-onboarding guidance calls for assessment of data accuracy, source reliability, fraud risk and end-to-end operation. The bank should test document substitution, presentation attacks, failed matches, overrides and the intended customer population. For unattended onboarding, the guidance calls for liveness detection and reliable comparison with the official-document image. If poor-quality information prevents reliable checks, the bank should stop and restart the process or redirect it to face-to-face verification. Contractual acceptance criteria must use test results agreed by the bank, without substituting an unsupported overall accuracy claim. (EBA/GL/2022/15, paras. 12–18, 39–41.)
Outsourcing does not make this software vendor a regulated third party on whose independent due diligence the bank can automatically rely. Article 29 distinguishes contractual outsourcing or agency treated as part of the obliged entity from the Directive's third-party-reliance provisions. The service description should reserve AML policy, risk acceptance, suspicious-activity judgment and final onboarding to the bank. (Directive (EU) 2015/849, Arts. 13, 25–29.)
A production agreement extending into July 2027 must address the enacted AML Regulation. From 10 July 2027, Article 18 requires prior supervisory notification of covered outsourcing and preserves the obliged entity's responsibility. It prohibits outsourcing the decisions on a customer's risk profile and establishment of a business relationship. The proposed score must remain an input to those bank decisions. Article 18 also imposes service-provider, subcontracting and specified third-country restrictions. (Regulation (EU) 2024/1624, Arts. 18(1)–(6), 90.)
Operative Indian duties and future DPDP changes
India's November 2025 commencement notification phases the DPDP Act. The main processing provisions in sections 3–17, other than section 6(9), and the section 44(2) change affecting Information Technology Act section 43A commence eighteen months after publication. They therefore do not yet replace the current processing rules for this transaction. Section 6(9), concerning Consent Manager registration, commences after one year. The contract should distinguish present requirements from obligations that arise during its term. (Digital Personal Data Protection Act 2023, ss. 1(2), 6(9), 44(2); G.S.R. 843(E), 13 November 2025.)
The 2011 SPDI Rules expressly include biometric and specified financial information. Their security, privacy-policy and transfer provisions remain relevant to an Indian processor. Rule 7 requires equivalent protection and either necessity for the specified lawful contract with the information provider or that provider's consent. The government's 24 August 2011 clarification states that Rules 5–6 do not apply to specified business-to-business contractual processing. That administrative clarification does not exempt the service from every SPDI requirement or from the EU bank's GDPR duties. (Information Technology SPDI Rules 2011, rr. 2(1)(b), 3–8; Department of Information Technology, clarification, 24 August 2011.)
CERT-In's directions require covered Indian entities to report specified cyber incidents within six hours of noticing them or being informed of them. They also require covered entities to enable logs of all their ICT systems and maintain those logs securely for a rolling 180 days within India. Those log requirements do not impose blanket Indian storage of all EU KYC files. The parties should minimize personal data in diagnostics, identify the required Indian logs and reconcile lawful retention with deletion commitments. (CERT-In Directions No. 20(3)/2022-CERT-In, 28 April 2022, directions (ii)–(iv).)
After the core DPDP provisions commence, section 17(1)(d) provides a conditional exemption for contracted processing of data principals outside India for a person outside India. Sections 8(1) and 8(5) remain outside that exemption, while its specified exemptions include section 16. The test concerns the principals' location and the contractual processing, rather than citizenship alone. Independent training or other purposes require separate analysis, and the exemption does not authorize GDPR transfers. (Digital Personal Data Protection Act 2023, ss. 8, 16, 17(1)(d).)
The proposed deliverables should exclude Aadhaar integration and Indian payment-system processing unless the parties commission separate product-specific review. Indian export controls address listed dual-use software and technology, with additional controls for specified end-use risks. Before exporting code, model weights or technical documentation, the vendor should document classification and satisfy any applicable authorization requirement. The contract should make clearance a release condition, without representing that all AI software is controlled or exempt. (Foreign Trade Policy 2023, Chapter 10, paras. 10.02–10.05; DGFT Handbook of Procedures, Chapter 10, July 2026 version, paras. 10.02, 10.04–10.05.)
The defensible pilot and contract sequence
A synthetic-data evaluation is the defensible first signature for this proposed product. The agreement should prohibit customer decisions, production connections and bank-data training, and require deletion at the end of testing. Truly anonymous data may serve the same purpose; pseudonymised customer records remain personal data where the relevant identification test is met. Even a test service remains subject to applicable ICT contracting duties. (GDPR, recital 26, Arts. 4(5), 28; DORA, Arts. 3(21), 28–30.)
A live shadow pilot is defensible only after the bank establishes its Article 6 basis and any Article 9 or 10 condition. It also needs the required impact assessment, security controls, processor terms, transfer safeguards and remote-onboarding assessment. Scores should remain outside operational decisions during the shadow stage. A trial falling within the AI Act's high-risk real-world-testing provisions needs the applicable testing plan, authority process and participant safeguards; an ordinary commercial “pilot” label supplies no exemption. (GDPR, Arts. 6, 9–10, 28, 32, 35–36, 44–46; AI Act, Arts. 60–61; EBA/GL/2022/15, paras. 13–18.)
Limited production is defensible once the bank has accepted evidence for the specified documents, users and operating conditions. The recommended scope permits document checks, sole one-to-one identity verification and advisory AML outputs, with genuine bank review. It excludes gallery search, creditworthiness reuse, emotion inference and autonomous onboarding decisions. Defined stop conditions, a tested manual fallback and bank approval of material changes should govern expansion. These are proposed acceptance controls derived from the identified risks, not measured performance findings. (GDPR, Arts. 24–25, 32; DORA, Arts. 28–30; EBA/GL/2022/15, paras. 14–18.)
The parties may negotiate a production master agreement before those gates close, but should defer production instructions, minimum-volume commitments and activation. Every arrangement for ICT services must satisfy the applicable pre-contract due-diligence requirements before signature; calling it conditional cannot avoid them. The schedules must resolve the processing entities, locations, permitted purposes, service levels, subcontractors, incident escalation, audit rights and tested exit. (GDPR, Art. 28; DORA, Arts. 28(4), 30; Delegated Regulation (EU) 2025/532, Art. 3.)
Commercial terms should allocate correction costs, intellectual-property rights, confidentiality, insurance, indemnities and liability without obstructing mandatory duties. The agreement should select a particular governing law and dispute forum, with separate attention to enforcement against the Indian supplier. Transfer clauses must retain their required precedence, third-party rights and governing-law and court provisions. Liability caps cannot remove a data subject's statutory remedies or the authorities' powers. (GDPR, Arts. 58, 79, 82; Decision (EU) 2021/914, Annex, clauses 3, 5, 12, 17–18.)
For this proposed transaction, the recommendation is an evaluation contract now, followed by gated EU-based limited deployment with identifiable data inaccessible to Indian support. India processing or identifiable support access becomes defensible only after a documented transfer assessment and effective safeguards support that exact flow. Production outsourcing of the defined checking service becomes defensible when the bank's validation, retained decisions and applicable contract requirements are satisfied. AI KYC compliance fails as a procurement proposition where the vendor requires unrestricted training reuse, hidden subcontractors, ineffective human review or audit and exit rights it cannot perform. (GDPR, Arts. 22, 28, 44–46; DORA, Arts. 28–30; Regulation (EU) 2024/1624, Arts. 18, 90.)