Executive Summary
- The Irish institution should begin with employee-approved recommendations, variant B, after a forecast-only shadow period. Its own payment gateway should construct, check and release instructions. The board retains policy and oversight; outsourcing cannot transfer senior management responsibility or the institution's liability for outsourced activities. European Union (Payment Services) Regulations 2018, S.I. No. 6/2018 (Irish Payment Regulations), regs. 18(1)(c), (5), 30(10), 31; Regulation (EU) 2022/2554, arts. 5, 28(1).
- Software may calculate forecasts, apply approved priorities and execute bounded rules. The proposed mandate reserves changes to safeguarding arrangements, liquidity floors, permitted counterparties and escalation duties to the institution's authorised staff. Customer payment orders require their own consent and execution rules. The firm's movement of its own liquidity is a separate instruction and legal relationship. Directive (EU) 2015/2366, arts. 3(m), 10, 64, 80; Irish Payment Regulations, regs. 17, 88, 104.
- An AI supplier does not need payment authorisation solely because its customer is regulated. A supplier that actually provides payment initiation or another payment service requires a separate perimeter assessment. Canadian law can also cover the initiation, transmission or facilitation of instructions, without custody of funds. Human approval and an EU-held signing key do not settle that classification. Directive (EU) 2015/2366, arts. 3(j), 4(15), 11; Retail Payment Activities Act, S.C. 2021, c. 23, s. 177, ss. 2, 4, 23.
- The hosted service requires controls under the Digital Operational Resilience Act (DORA) across all three variants. Enhanced contract terms depend on whether it supports a critical or important function, judged by the consequences of failure. Access, audit, location, subcontracting, incident support, recovery and exit rights must work across the Canadian supply chain. Regulation (EU) 2022/2554, arts. 3(21)–(22), 28–30.
- Treasury forecasting and payment sequencing are not automatically high-risk uses under the AI Act. Creditworthiness assessment, employee evaluation or another listed purpose can change the classification. Transaction and employee data require their own General Data Protection Regulation (GDPR) analysis of purposes, processing and transfers. Canada's adequacy decision covers recipients subject to its federal privacy statute, PIPEDA. Regulation (EU) 2024/1689, arts. 2–4, 6, Annex III, as amended by Regulation (EU) 2026/1744; Regulation (EU) 2016/679, arts. 5–6, 22, 28, 44–46; Commission Decision 2002/2/EC, art. 1.
- A stop button prevents further instructions only where the institution still controls release. After receipt or entry into a payment system, cancellation depends on applicable law, the mandate and system rules. A supplier indemnity cannot reverse settlement or remove customer redress duties. Irish Payment Regulations, regs. 31, 97, 104, 112–116; European Communities (Settlement Finality) Regulations 2010, S.I. No. 624/2010, regs. 6–7.
- Expansion to agent-initiated operations, variant C, should require evidence from adverse-condition tests, meaningful human intervention, independent limits and supplier-independent recovery. Initial autonomy should cover only approved transfers of the institution's own funds between named accounts. Customer-facing payment priorities need a separate assessment of consent, deadlines and individual effects. Regulation (EU) 2022/2554, arts. 9–12, 24–25, 28(8); Irish Payment Regulations, regs. 17, 88, 103–107; Regulation (EU) 2016/679, art. 22.
The three variants and the two flows of money
Variant B offers the most defensible initial live operating model for this institution. It permits useful decision support while preserving an identifiable employee's decision before release. That recommendation depends on the employee having current information, sufficient time and authority to reject the proposal. A hurried approval click does not supply those controls.
The institution in this case is an authorised Irish payment institution. It holds customer funds under the segregation method of safeguarding and uses banks and payment-system connections to execute payments. It also holds its own operating funds. The proposed initial deployment uses bank-mediated access; it does not assume that the institution is itself a direct member of a designated settlement system.
In variant A, the Canadian service forecasts incoming and outgoing cash and displays expected balances. It has no route to change a payment queue or issue an instruction. Staff continue to operate the existing treasury process. A forecast can still become operationally important if staff depend on it for timely funding.
Variant B adds recommended priorities and transfers. In the proposed design, these are non-executable recommendations. An Irish treasury employee selects an action in the institution's own system. That system constructs the payment message from trusted account records, checks limits and releases it through an approved bank channel. The Canadian service holds no production payment credential.
Variant C permits the software to select and initiate actions within an approved mandate. It might reorder already authorised customer payments or transfer the firm's own liquidity between accounts. Those are separate permissions. A customer's payment instruction authorises the customer's transaction under its agreed terms. It does not authorise unrelated movement of the institution's money, and a treasury mandate does not supply missing customer consent. Irish Payment Regulations, regs. 88, 102–104.
The distinction affects remedies too. Transactions between payment service providers for their own account can fall outside the payment-services rules under regulation 4(1)(m). The institution's corporate bank relationship can also involve permitted contractual departures from specified rules. Customer payment claims therefore cannot be analysed by assuming that every treasury transfer receives the same statutory treatment. Irish Payment Regulations, regs. 4(1)(m), 85.
Decisions that the institution must retain
The institution may delegate performance of defined tasks; its board and senior management retain responsibility for the business. Irish law requires clear responsibilities, risk controls and effective management. Outsourcing an important operational function must not impair internal control or the Central Bank of Ireland's supervision. It cannot delegate senior management responsibility, alter obligations to payment users or undermine authorisation conditions. Irish Payment Regulations, regs. 18(1)(c), (5), 30(8)–(10).
The board should approve the liquidity risk appetite, minimum balances, safeguarding policy, permitted accounts, funding sources and escalation rules. Treasury management should set and maintain numerical limits within that policy. Risk and compliance should challenge changes and monitor breaches; security staff should control identities and credentials. The Canadian provider may maintain the model under agreed change controls. It should have no permission to raise limits, add beneficiaries, borrow, change safeguarding arrangements or bypass a control after a rejection.
Software can calculate balances, forecast demand, rank eligible payments against approved criteria and test proposed actions against fixed constraints. Even C can remain an outsourced execution process if the institution controls its purpose, mandate, limits and supervision. A service in which the vendor chooses risk appetite, decides which customer obligations to honour or exercises unreviewable discretion over liquidity would defeat that allocation of responsibility. A contractual statement that the institution remains accountable cannot cure the loss of actual control. Irish Payment Regulations, regs. 30(10), 31; Regulation (EU) 2022/2554 (DORA), arts. 5(2), 28(1)(a).
The proposed mandate excludes investment selection, foreign-exchange speculation and autonomous borrowing. The Central Bank's applicant expectations reinforce the need for internal capability and effective risk and compliance functions; they are supervisory expectations, distinct from the binding outsourcing prohibition. Central Bank of Ireland, Expectations for Authorisation of Payment and Electronic Money Institutions and Registration of Account Information Service Providers (April 2024), pp. 18–19.
The supplier's payment-services perimeter
The supplier's actual service determines whether it crosses the EU payment-services boundary. PSD2 excludes supporting technical services that never possess the funds, but expressly removes payment initiation and account information services from that exclusion. Payment initiation involves initiating a payment order at a user's request on an account held at another provider. A corporate institution can be that user. Absence of custody alone does not establish the exclusion. Directive (EU) 2015/2366 (PSD2), arts. 3(j), 4(15), Annex I; Irish Payment Regulations, reg. 4(1)(j).
A dashboard confined to forecasts has a strong technical-service basis. B requires examination of what occurs after approval: if the Canadian interface packages or submits the instruction as a service to the account holder, an approval step does not resolve the perimeter. C requires the closest assessment of who initiates the order, whose service the customer uses and whether the supplier acts as a technical processor, a statutory agent or a payment service provider. Internal automation controlled by the institution does not automatically make the hosting company a payment institution.
Where the supplier does provide a regulated payment service in Ireland, the relevant authorisation or legally available registered-agent route must cover that service. The software label "agent" does not establish registered-agent status. A Canadian registration supplies no EU passport. Irish law prohibits unauthorised provision and requires registration before a payment institution's legal agent provides payment services. Irish Payment Regulations, regs. 6, 18, 30(1)–(3). Licentium's payments and e-money licensing guide provides a reader's starting point for mapping activities and funds flows.
Canada requires its own analysis. The Retail Payment Activities Act (RPAA) applies to an in-scope payment service provider with a Canadian place of business, even if its client and euro accounts are abroad. Its payment functions include initiating transfers and authorising, transmitting, receiving or facilitating instructions. The function must be a non-incidental service or business activity, and statutory exclusions must be tested. Retail Payment Activities Act, ss. 2, 4–10.
The Bank of Canada's official interpretation identifies a service that helps other providers populate standardised payment instructions as possible facilitation. That guidance makes a structured, executable proposal a material issue even where an Irish employee signs it. The proposed B therefore keeps message construction inside the institution and requires a documented Canadian perimeter determination before launch. This is a control design, not a finding that every recommendation service is excluded. Bank of Canada, Criteria for Registering Payment Service Providers (updated 29 June 2026), sections "Transmission, reception, or facilitation of an instruction" and "Incidental activities".
Nor does a transfer between the client's own accounts establish Canada's internal-transaction exclusion. Section 8 requires the relevant affiliation conditions, including the provider's affiliation; an independent vendor ordinarily fails that condition. The agent exclusion requires an RPAA-registered principal and the section 10 conditions. If registration is required, it must precede the new activity under section 23. A distinct Canadian money-services assessment is also necessary if the supplier enters the business of remitting or transmitting funds. Retail Payment Activities Act, ss. 8, 10, 23; Proceeds of Crime (Money Laundering) and Terrorist Financing Act, S.C. 2000, c. 17, ss. 5(h)(ii), 11.1.
Safeguarding constrains every liquidity decision
Customer funds cannot become a discretionary source of corporate liquidity. Under the chosen segregation method, the institution must separate relevant customer funds, protect them from other creditors and place qualifying retained funds in the prescribed safeguarded arrangements. The next-business-day placement rule does not grant an intraday permission to finance the institution's own expenses with customer money. Irish Payment Regulations, reg. 17; PSD2, art. 10.
The system should maintain distinct records for safeguarded funds, funds committed to customer execution, the institution's own cash and available committed credit. A transfer between safeguarding accounts requires its own approved process and continuing compliance. It should sit outside the proposed initial agent mandate. Bank account labels, ledger balances and available-to-spend balances must be reconciled; an apparent cash surplus does not establish that the money is the institution's own.
A liquidity shortfall should trigger the approved funding and incident process. Treasury may draw a committed facility through an authorised human decision, transfer eligible own funds or adjust discretionary own-account movements. Software must not invent a financing source or delay customer obligations merely to improve a forecast. An authorised customer order meeting contractual conditions cannot be refused unless prohibited by law, and applicable execution deadlines continue to run. Irish Payment Regulations, regs. 103(4), 107.
Instant payments make timing especially important. Where the instant-euro rules apply, the recipient's provider must make funds available within the statutory ten-second process. The euro-area payment-institution deadline to offer sending and receiving instant transfers is 9 April 2027. The architecture must place treasury approvals upstream of accepted instant customer orders; it cannot add a discretionary approval queue inside that execution clock. Regulation (EU) No. 260/2012, art. 5a(4)–(5), (8), as inserted by Regulation (EU) 2024/886.
DORA and the Canadian outsourcing contract
DORA applies to the ongoing hosted information and communication technology (ICT) service in A, B and C. Its coverage does not depend on proving that every software purchase is outsourcing. The institution must assess whether the supplier performs a process or activity it would or could realistically undertake itself. Prior internal performance is unnecessary. Here, ongoing liquidity forecasting and operational decision support performed on the institution's behalf support that classification. DORA, arts. 2(1)(b), 3(21), 28; European Banking Authority (EBA), Guidelines on Outsourcing Arrangements, EBA/GL/2019/02, paras. 26–28.
Criticality turns on impact. A can be non-critical if it is an optional dashboard and independently tested processes preserve service during its loss. B can support a critical or important function if its failure materially impairs payment continuity or compliance, despite human approval. C's ability to release instructions creates a stronger operational dependency, but the statutory test still applies to the actual arrangement. The institution should procure the proposed B with the enhanced terms for critical functions and document its formal classification. DORA, arts. 3(22), 28(4), 30(3).
The institution must keep its DORA register of ICT contracts, perform prior risk and concentration assessments, and inform its supervisor in a timely manner about planned ICT arrangements supporting critical or important functions. Irish regulation 30(7) separately requires at least 30 days' prior notification of intended outsourcing of operational functions. Notification does not transfer accountability or supply a missing payment authorisation. The EBA's 2019 outsourcing guidelines and the Central Bank's Cross-Industry Guidance on Outsourcing remain relevant supervisory expectations alongside binding DORA requirements. DORA, arts. 28(3)–(4), 29; Irish Payment Regulations, reg. 30(7); Central Bank of Ireland, Cross-Industry Guidance on Outsourcing (December 2021).
If deployment materially changes the business model or extends authorised services, the institution must also satisfy the Central Bank's corresponding prior-approval process. A larger C mandate can therefore require more than an outsourcing notification. Central Bank of Ireland, Amendments Processing for Payment Institutions, sections "Application for Extension of Authorisation" and "Application for Material Change of a Business Model".
For an outsourced banking or payment function that would itself require authorisation or registration in Ireland, the EBA expects the third-country provider to be authorised or registered and effectively supervised. It also expects an appropriate supervisory cooperation agreement as a condition for that outsourcing. The institution must address those conditional expectations if the supplier's actual function meets the threshold. EBA/GL/2019/02, paras. 62–63.
Every ICT contract needs clear service descriptions and service levels, locations of service provision, processing and storage, advance location-change notice and data protection terms. It must provide usable data recovery and return rights, incident assistance at no extra or pre-agreed cost, authority cooperation, termination and relevant training participation. A confidentiality clause must permit the institution to meet its regulatory duties. DORA, art. 30(2).
For support of a critical or important function, the contract must also provide precise performance targets, material-change reporting, tested contingency arrangements and cooperation with applicable testing. The institution and competent authorities need effective access, inspection and audit rights. Certifications or pooled audits can contribute evidence; they cannot eliminate necessary access. A defined transition period must permit migration or reintegration without unacceptable interruption. DORA, art. 30(3); Commission Delegated Regulation (EU) 2024/1773, art. 8(2)–(3).
The supplier should identify the cloud host, model provider, inference services, support operators and other material subcontractors. For subcontracting that supports critical or important functions, the institution must assess the chain, geographic and concentration risks. The contract must specify permitted services and conditions, advance notice of material changes and a reasonable assessment period. Changes may proceed only after approval or expiry of that period without objection. Required access, audit and continuity obligations must extend through the relevant chain. The institution must object and seek modifications where the risk exceeds its tolerance, with termination rights in the specified cases. The supplier remains responsible for contracted performance. Commission Delegated Regulation (EU) 2025/532, arts. 3–6; DORA, arts. 28–30.
Canadian hosting creates questions about enforceable audit access, public-authority demands, insolvency, recovery and exit. It does not itself create a DORA ban. The rule requiring a third-country critical ICT provider to establish an EU subsidiary within 12 months of designation concerns providers designated critical by the European Supervisory Authorities. It is not triggered merely because one client classifies its supported function as critical. DORA, art. 31(12).
Concentration assessment must extend beyond the named vendor. Two suppliers can share the same cloud region, model service or identity system. The institution should test a fallback that remains usable when that common dependency fails. The exit plan should cover export of data and logs, continued access, replacement models or manual processes, transition assistance and deletion. Contractual exit rights alone do not establish that migration can meet payment deadlines. DORA, arts. 11–12, 28(8), 29.
AI Act classification follows the actual purpose
The Canadian company is normally the AI-system provider if it develops or commissions the system and markets it under its own name. The Irish institution is normally the deployer using it under its authority. The Act applies to relevant providers outside the EU and to specified uses of outputs in the EU. Integration, branding and the underlying model supply chain can alter the role analysis. Regulation (EU) 2024/1689 (AI Act), arts. 2(1), 3(1), (3)–(4), (6).
Forecasting the firm's balances or sequencing payments under fixed operational criteria is not, by itself, an Annex III high-risk category. Neither regulated status nor DORA criticality supplies that classification. The actual use must be tested against Article 6 and the listed purposes, including specified critical-infrastructure safety uses. A model that evaluates natural persons' creditworthiness falls within Annex III, point 5(b), subject to its fraud-detection exception. A model used to assess employee performance or allocate work by individual behaviour can fall within point 4(b). AI Act, art. 6, Annex III, points 2, 4(b), 5(b).
The institution should prohibit those additional uses in the initial mandate and reassess classification before introducing them. Human approval does not itself establish the Article 6(3) exception for certain Annex III systems. That exception has its own conditions; the profiling rule applies within the Annex III class. Permitted configuration should also be distinguished from changes of purpose or substantial modifications. Article 25 can assign provider obligations for specified high-risk-system changes when that part of the Act becomes applicable. AI Act, arts. 3(12), (23), 6(3)–(4), 25, 113.
The amended timetable matters. Chapter III, sections 1–3, apart from Article 6(5), apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The later dates do not suspend current payment, DORA or GDPR duties. Article 4 already requires measures supporting staff AI literacy. The relevant employees should learn how to identify stale data, interpret forecast uncertainty, reject unsuitable outputs and operate the fallback. AI Act, arts. 4, 113, as amended by Regulation (EU) 2026/1744, art. 1(5), (40).
The institution and provider must assess Article 50 against the actual interface and output. A conversational interface directly interacting with staff may require disclosure that they are interacting with AI, unless that is obvious under the statutory test. Generated narrative recommendations can engage the provider's synthetic-content marking rules. The transition to 2 December 2026 for Article 50(2) concerns systems placed on the market before 2 August 2026; it is not a general transparency postponement. AI Act, arts. 50(1)–(2), 111(4), 113.
Transaction data, employees and international transfers
The Irish institution remains responsible for its GDPR purposes and essential processing choices. Transaction-level records and identifiable approval logs can contain personal data even when customers include companies. Stable pseudonymous identifiers can remain personal data. The Canadian supplier is ordinarily a processor when it acts only on documented instructions; independent reuse for its own model training can make it a controller for that processing. Regulation (EU) 2016/679 (GDPR), arts. 3(1), 4(1), (5), (7)–(8), 28(10).
The initial service should receive only fields needed for forecasts and approved controls. Amount, currency, timing and account class often permit analysis without names or free-text payment narratives. The latter can disclose sensitive personal information. Each purpose requires a valid legal basis, proportionate retention, notices and access controls. A customer's payment contract does not supply blanket permission for the vendor to train products for other customers. GDPR, arts. 5–6, 9, 13–14, 25. Licentium's data protection guide for AI introduces the separate questions of lawful use, processing terms and individual rights.
Payment-services data rules impose a separate restriction. For those services, the institution may access, process and retain necessary personal data with the user's explicit consent. The European Data Protection Board (EDPB) interprets that consent as an additional contractual requirement. It does not replace the GDPR lawful basis or authorise unrelated model training. Irish Payment Regulations, reg. 117(3); PSD2, art. 94(2); EDPB Guidelines 06/2020 on the Interplay of PSD2 and the GDPR (15 December 2020), pp. 14–15.
The processing agreement must specify instructions, confidentiality, security, subprocessor approval, assistance with rights and incidents, return or deletion and audit information. Model updates must not expand purposes or recipients silently. For this deployment, the institution should complete a data protection impact assessment before live use. Article 35 makes that assessment mandatory where processing is likely to create high risk; AI alone is not the test. Unmitigated high residual risk requires prior consultation under Article 36. GDPR, arts. 28, 35–36.
Article 22 concerns solely automated decisions with legal or similarly significant effects on natural persons. Movement of the institution's own cash ordinarily decides an institutional treasury matter. Customer queue decisions require closer examination if they determine access to funds or cause material delays. A routine ordering difference is not automatically a significant individual effect. If Article 22 applies, the institution needs an applicable exception and safeguards; an Article 6 legitimate-interest basis alone is insufficient. GDPR, art. 22.
B must therefore provide real human assessment wherever it is relied on to avoid solely automated decision-making. The reviewer needs relevant evidence, competence and authority to change the result. Approval of a bulk treasury action does not necessarily review each customer's treatment. Official interpretative guidance requires meaningful involvement and rejects fabricated human intervention. Article 29 Working Party, Guidelines on Automated Individual Decision-Making and Profiling, WP251 rev.01 (6 February 2018), pp. 20–21, endorsed by the EDPB on 25 May 2018.
Where the GDPR's automated-decision information duties apply, the institution must give affected individuals meaningful information about the logic, significance and consequences of that processing. The supplier contract and retained evidence should enable those disclosures and the applicable rights to human intervention and contest. GDPR, arts. 13(2)(f), 14(2)(g), 15(1)(h), 22(3).
Canada's adequacy decision applies to recipients subject to the Personal Information Protection and Electronic Documents Act (PIPEDA) for the relevant processing. The institution must establish that coverage for the receiving entity and activity. Commercial processing of Irish transaction and employee data can engage PIPEDA; its separate employee provision does not cover every ordinary Ontario employer's personnel records. Commission Decision 2002/2/EC, arts. 1–2; PIPEDA, S.C. 2000, c. 5, s. 4(1).
An in-scope adequate transfer does not require standard contractual clauses merely because hosting is Canadian. The institution must still map support access, inference, backups, telemetry and onward recipients. For transfers outside the adequacy coverage, it needs another lawful route. Where it relies on the EU standard contractual clauses, the correct modules, completed annexes, destination-law assessment and necessary supplementary measures must fit the actual chain. GDPR, arts. 44–46; Commission Implementing Decision (EU) 2021/914, Annex, cls. 8.8, 9, 14–16.
Instruction authority, irrevocability and losses
The bank mandate must define which identities may release instructions and which limits bind the bank's acceptance process. Internal policy alone does not establish that a bank must reject an instruction outside it. The proposed design places signing credentials under the institution's control, uses separate service identities and restricts recipients and channels. Applicable strong customer authentication requirements remain relevant. The corporate-process exemption has specific conditions, including equivalent security accepted by competent authorities. Irish Payment Regulations, reg. 120; Commission Delegated Regulation (EU) 2018/389, art. 17.
Before release, the institution can cancel an internal proposal and revoke the agent's permissions. Removing an instruction from a local queue does not itself cancel a customer payment order already received by the institution or otherwise made irrevocable. After a payer's provider receives a payment order, regulation 104 generally prevents unilateral revocation, with specific rules for initiation services, direct debits and agreed future execution. A later cancellation requires the relevant agreements. The institution should record the actual receipt and cancellation events, not infer them from a local status display. Irish Payment Regulations, regs. 102, 104.
Settlement finality adds another boundary. Designated-system rules specify entry and the point after which a transfer order cannot be revoked. Statutory protection for transfer orders and netting also operates in insolvency. A stopped model, restored database or reversed local ledger entry cannot undo those legal effects. Recovery can require a permitted recall, a recipient's repayment or a fresh compensating transaction. European Communities (Settlement Finality) Regulations 2010, regs. 6–7; Directive 98/26/EC, arts. 3, 5.
A model's breach of an internal limit does not automatically prove that the payment was unauthorised by its payer. The consent arrangement, mandate and actual instruction matter. Where a customer payment is unauthorised, the statutory refund rule generally requires the payer's provider to refund immediately and no later than the end of the following business day after awareness, subject to the fraud-suspicion exception. Recorded authentication alone does not necessarily prove authorisation. Notification limits, applicable payer-liability rules and permitted non-consumer derogations must also be applied. Irish Payment Regulations, regs. 85, 88, 95–98.
Authorised but non-executed, defective or late payments engage a different liability route. The institution remains liable for outsourced activities and cannot direct customers to pursue the Canadian model supplier instead. Statutory execution liability, additional compensation and recourse provisions govern their respective relationships. Abnormal and unforeseeable circumstances can supply a defence only within the statutory conditions; a Canadian outage does not establish that defence by itself. Irish Payment Regulations, regs. 31, 112–116.
For the firm's own liquidity transfer, the bank contract and any applicable statutory exclusions or derogations require a separate allocation. An instruction that the bank was entitled to accept may leave the institution to claim against its supplier. The provider contract should allocate erroneous-transfer and duplication losses, customer-redress support, investigation costs, indemnities, liability caps and insurance. Those negotiated remedies should be assessed against plausible losses and the supplier's financial capacity, not inferred from an uptime promise.
The recommended provider contract selects Irish law and an agreed dispute forum, with effective service and recovery arrangements. Rome I permits a contractual choice of law and preserves applicable overriding mandatory rules. It excludes the external question whether an agent can bind a principal, so the vendor contract's law clause cannot settle the bank mandate's authority question. Canadian payment and privacy statutes apply according to their own scope. Regulation (EC) No. 593/2008, arts. 1(2)(g), 3, 9, 12. Contract allocation must leave the institution able to meet its own regulatory and customer obligations.
A defined initial operating model
The recommended live deployment is B, following A in shadow operation. The board approves policy; the treasury head owns day-to-day parameters; risk and compliance review their adequacy; security controls the release credentials. A named treasury employee accepts or rejects each proposed action. A second authorised employee should approve high-value transfers, new operational exceptions and changes to limits. Neither reviewer may bypass a safeguarding prohibition through an approval button.
The Canadian service supplies analysis only. The institution's EU-controlled gateway independently retrieves current balances, verifies account identity and constructs the instruction. It checks the permitted account pair, currency, available own funds, reserved commitments, minimum residual balance, single-transfer cap and aggregate caps. The gateway must reject stale proposals and unsupported instructions even after employee approval. Identity separation, least privilege, controlled changes and protected logs implement existing ICT duties. DORA, art. 9; Commission Delegated Regulation (EU) 2024/1774, arts. 12, 17, 20–21.
In B, the permitted amount of an unapproved model-initiated transfer is zero. Future C limits should be derived from stressed payment demand, funding delay, uncertainty and recoverable loss. An illustrative own-funds envelope might allow €50,000 per transfer, €250,000 in any rolling 15 minutes and €1 million per day. These figures are proposed test settings, not regulatory thresholds or a finding that this institution can afford those exposures.
Suppose the source account contains €1.2 million of eligible own cash, previously reserved outgoing commitments are €200,000 and its required residual balance is €500,000. Available headroom from that account is €500,000. Under the proposed design, a new transfer must satisfy that headroom and each remaining single, rolling and daily allowance. Concurrent workers must reserve funds atomically against the same ledger. Gross-transfer and transaction-count limits must prevent repeated small instructions from defeating the cap. Forecast inflows should not count as cash already available. The design requires separate limits for each account, currency and relevant counterparty, with no automatic limit increase during stress.
The institution needs local authority to suspend recommendations, disable releases and revoke credentials. Its treasury duty officer should receive liquidity and limit alerts; risk, compliance and security should receive incidents within their remits. The incident commander owns coordination and regulatory classification. The data protection officer receives suspected personal-data breaches. The supplier must notify named contacts promptly and preserve evidence; its investigation must not become a precondition for the institution's response.
The decision record should preserve data timestamps and quality, balance and reservation snapshots, model and policy versions, the proposal, deterministic checks, the employee's decision and any override. It should also contain the exact released instruction, unique identifiers, bank acknowledgements, settlement status and cancellation attempts. Logs must remain accessible to the institution during a Canadian outage and support examination by risk, audit and regulators. Re-running a changed or nondeterministic model is not a substitute for the actual record. DORA, arts. 10–12, 17; Commission Delegated Regulation (EU) 2024/1774, art. 12.
Retention should match legal purpose and data necessity. Irish regulation 32 requires appropriate records under the authorisation part for at least five years; that does not require indefinite storage of every personal-data field or raw model trace. GDPR accountability, storage limitation and applicable access rights remain relevant. The record should explain what information and controls produced the action without depending on an unverifiable model narrative. Irish Payment Regulations, reg. 32; GDPR, arts. 5(1)(e), 5(2), 15.
Five failures the institution must be able to contain
A liquidity shortfall should stop optional own-account transfers that would breach the floor. Treasury should receive the projected deficit, affected deadlines and available approved funding choices. Staff must continue the customer-payment process within its legal constraints and escalate any threatened breach. A model recommendation to use safeguarded funds for corporate expenses must fail at the gateway. Irish Payment Regulations, regs. 17, 103–107.
Model drift requires a measured trigger. The institution should compare forecast error, uncertainty calibration and priority outcomes against an approved baseline, by currency and relevant payment period. A breach should suspend reliance on the model and activate the tested deterministic or manual process. The supplier must not replace the model silently. Deployment, rollback and revalidation require controlled versions, independent change approval and tested recovery. Commission Delegated Regulation (EU) 2024/1774, art. 17.
An erroneous €2 million instruction should never reach the bank under the illustrative €50,000 transfer cap. A has no instruction path; any resulting staff instruction remains subject to existing release controls. In B the employee and independent gateway should reject it. In C the gateway must reject it without waiting for a person. If an instruction has already escaped, staff must establish its bank and system status, request any available cancellation and prevent duplicate retries. Customer redress and supplier recourse then follow the applicable legal relationship. Irish Payment Regulations, regs. 97, 104, 112–116.
Simultaneous payment surges require testing across accounts, currencies, workers and shared providers. Independent agents must not spend the same available balance or repeatedly move cash in response to each other's actions. The test should include correlated demand, delayed incoming funds, bank cut-offs and exhausted funding lines. Approval capacity must remain sufficient under those conditions. If it does not, the institution must reduce the scope of B or use its established deterministic process; it cannot treat overload as permission for unapproved C. DORA, arts. 11, 24–25.
An unavailable Canadian service should suspend its advice while the institution continues through EU-accessible bank channels and its tested fallback. That fallback needs current balances, credentials, account directories, decision logs and an authorised staff rota independent of the supplier. Recovery must reconcile all in-flight instructions before resubmission. An unknown payment state is not permission to replay the order. DORA, arts. 11–12, 28(8).
The incident process must run alongside containment. Major status depends on the prescribed impact thresholds; an erroneous high-value instruction is not automatically reportable as major. Payment operational and security incidents fall within DORA's relevant chapter, including non-ICT incidents. Major incidents must reach relevant senior management and the board. Where a major incident affects clients' financial interests, the institution must inform them without undue delay. DORA, arts. 17(3)(e), 19(3), 23; Commission Delegated Regulation (EU) 2024/1772, arts. 6, 8–9.
The initial major-incident report is due as early as possible, within four hours of classification and no later than 24 hours after awareness. If classification occurs after those 24 hours, the deadline is four hours from classification. An intermediate report is due within 72 hours of the initial notification, with required updates and a report when regular activities resume. The final report is due within one month of the latest intermediate report. The contract should support continuous response without reliance on weekend or bank-holiday extensions. Commission Delegated Regulation (EU) 2025/301, art. 5.
Personal-data breach duties use a separate test. A processor must notify the controller without undue delay after becoming aware of the breach. The controller's supervisory notification is due without undue delay and, where feasible, within 72 hours after becoming aware of the breach, unless the breach is unlikely to risk individuals' rights and freedoms. High-risk breaches require the Article 34 communication assessment. Under PIPEDA, the organisation with control must report and notify qualifying breaches as soon as feasible after determining that the breach occurred. The Canadian threshold is a real risk of significant harm. GDPR, arts. 33–34; PIPEDA, ss. 10.1–10.3. A contract should require supplier alerts early enough to support all applicable clocks.
Evidence required before autonomy expands
C should begin only after the institution demonstrates that each permitted action can remain inside independently enforced constraints during adverse conditions. Evidence should include shadow comparisons against the existing process, replay of representative historical periods and synthetic shortfalls, data corruption, instruction injection, surges and supplier failure. Tests must measure forecast error, missed deadlines, control breaches, duplicate prevention, staff response and recovery time. DORA, arts. 24–25; Commission Delegated Regulation (EU) 2024/1774, art. 17.
For a non-microenterprise, appropriate tests of all ICT systems and applications supporting critical or important functions are required at least yearly. Tests require appropriate independence. Threat-led penetration testing applies to entities selected under DORA's criteria, ordinarily at least every three years, subject to supervisory adjustment. The institution must establish which testing duties apply to its size and designation. DORA, arts. 24(4), (6), 26(1), (8); Commission Delegated Regulation (EU) 2025/1190, art. 2.
The first C mandate should cover named same-currency transfers of the firm's own funds between approved accounts, with no new beneficiary, borrowing, investment or safeguarding-account change. Customer sequencing should require a separate approval of its lawful priorities, execution effects and GDPR Article 22 assessment. Board approval should identify the exact model version, limits, stop conditions and accountable owner. Changes to purpose, model, subcontractor, data location or instruction authority should trigger a proportionate reassessment before release. Irish Payment Regulations, regs. 17, 27, 30–31; DORA, arts. 28–30; GDPR, arts. 22, 35(11).
The BIS research provides a reason to test these problems, not evidence that a product has regulatory approval. Its cash-management study uses a stylised payment-system setting; the operator demonstration uses a form rather than live payment rails. Its authors identify further work on validation, multi-agent behaviour and adverse conditions. Iñaki Aldasoro and Ajit Desai, AI Agents for Cash Management in Payment Systems, BIS Working Papers No. 1310 (November 2025), pp. 2–4, 16–20. A simulation cannot establish authorisation, lawful data transfers, enforceable mandates or safe performance in this institution.
Live deployment should be held if the supplier's regulated role is unresolved, required authorisation or registration is absent, or the bank mandate does not support the proposed release process. Other stopping conditions include inaccessible audit records, an unlawful transfer path, unapproved training reuse, inadequate review capacity, uncontrolled model changes and a failed supplier-independent recovery test. The institution should keep production payment credentials disabled until those conditions are resolved. Its authority to operate, duties to customers and ability to control the service must be demonstrated for the precise deployment it approves. Irish Payment Regulations, regs. 6, 17–18, 30–31; DORA, arts. 28–30; GDPR, arts. 28, 35–36, 44–46.