The first question is whether another control independently blocks execution without approval. If it does, the parties must verify its coverage. If it does not, the fintech should disable the action permission while the supplier separates proposal preparation from execution. The legal assessment then follows the particular action, each operator’s role and the countries connected to the service.
Executive Summary
- The fintech must define the supplier’s mandate and its own approval hierarchy. A payment additionally requires the payer’s consent under the agreed procedure. An internal approval failure does not alone establish an unauthorised payment. (Payment Services Regulations 2017, SI 2017/752, reg. 67.)
- UK duties depend on the fintech’s actual regulated activity and the supplier’s territorial connection. Outsourcing does not transfer a payment institution’s statutory responsibility to the supplier. (Payment Services Regulations 2017, regs. 25, 36 and 138; FCA Handbook, PERG 15.6, Q46.)
- Indonesian electronic-system, electronic-agent and personal-data duties require a separate assessment. The supplier is not automatically the statutory agent operator merely because it supplies the connector. (Law No. 11 of 2008, as amended, arts. 1(8), 15 and 21; Government Regulation No. 71 of 2019, arts. 36–40.)
- Separate read, draft and execution permissions. Bind approval to the exact operation and check it at execution. These are proposed controls for the agreed workflow; MCP documentation and the applicable security duties support their design. (MCP Specification, 2026-07-28, Authorization and Tools; UK GDPR, art. 32; Government Regulation No. 71 of 2019, art. 40.)
- Allocate containment, notification, evidence, correction and financial recovery expressly. Contractual recourse cannot remove payment users’ statutory remedies or applicable data-protection obligations. (Payment Services Regulations 2017, regs. 75–76; UK GDPR, arts. 28, 33–34 and 82; Indonesian Law No. 27 of 2022, arts. 46 and 51–52.)
One credential reaches records and operational actions
The permission problem spans two connections: the agent client’s access to the MCP server and the server’s access to the fintech system. Restricting only the first leaves any broader downstream credential to be examined. The inventory should identify each tool, calling identity, target system, account and permitted operation.
The current MCP authorisation specification distinguishes access to the MCP server from access to an upstream API. It requires audience validation and prohibits passing an incoming client token through to that API. The upstream token must be separate. Tool annotations also require care: a readOnlyHint describes intended behaviour; it does not enforce a permission boundary. (MCP Specification, 2026-07-28, Authorization: Security Considerations, “Token Audience Binding and Validation” and “Access Token Privilege Restriction”; Tools, “Security Considerations”; Schema Reference, “ToolAnnotations”.)
Inspect the enforcement point before drawing a conclusion from scope alone. A backend gate may already reject an action lacking a valid approval. Its existence, coverage and failure behaviour need evidence. A prompt telling the model to ask a human is insufficient where an execution path can bypass that instruction.
The proposed correction has four stages: the agent reads permitted information, prepares an exact proposal, an authorised person approves it, and a separate control permits that approved operation. The fintech should withhold action access until this sequence works across every execution route. The broader allocation is discussed in delegated machine authority.
The mandate must identify who can commit the fintech
The fintech’s authorised decision-makers approve the supplier engagement and delegate operational powers through the contract and internal mandate. The credential issuer implements access. The human approver exercises a defined decision right. The operator runs the agent. One organisation may perform several roles, but the records must identify them separately.
The master services agreement and statement of work should identify permitted actions, affected systems, authorised approvers and forbidden changes. Include payment and record-change limits, delegation rights, escalation and suspension. Record whether the supplier operates the agent, hosts only the MCP server, or supplies software operated by the fintech. Technical access and contractual authority should then agree.
Payment instructions require a payer-authorisation analysis
A payment is authorised under the UK payment rules only where the payer has consented to its execution. Consent may cover one transaction or a series, using the form and procedure agreed with the payment service provider. Human approval for every transaction is not a universal statutory requirement. The agreed internal workflow can impose a stricter condition. (Payment Services Regulations 2017, reg. 67(1)–(2).)
Identify the payer and the instruction that reaches its payment service provider. The fintech may be paying its own money or providing a service to another payer. Check whether the relevant mandate permits automated instructions and whether the required consent exists. A breached employee-approval policy does not, without that analysis, determine the payment’s statutory status.
An electronic payment can also engage strong customer authentication and, for remote electronic payments, dynamic linking to amount and payee. Apply the relevant technical-standard exemptions. A server credential or internal approval flag is not automatically compliant authentication. (Payment Services Regulations 2017, reg. 100(1)–(5).)
Customer-record changes require a defined processing purpose
A record-edit tool processing personal data needs an authorised purpose, a lawful basis and controls over accuracy and access. An incorrect change may compromise data integrity even without disclosure. The fintech should identify which fields the agent can change and which changes affect customer rights. (UK GDPR, arts. 5–6, 28 and 32; Indonesian Law No. 27 of 2022, arts. 20, 27–29, 35–39 and 51–52.)
Where a record change implements a significant decision made solely by automated processing, assess the current UK rules in Articles 22A–22D. These include information, representations, human intervention and contest safeguards, with additional restrictions for special-category data. Human involvement must be meaningful; an approval label alone does not establish it. (UK GDPR, arts. 22A–22C.)
Draft recommendations can remain within a narrower mandate
A tool that prepares a proposal without changing records or transmitting an instruction has a narrower operational effect. Data-protection duties still apply to the personal data it uses. Keep the output unexecuted until the authorised person accepts it through the approved route. If the output itself becomes regulated advice or a significant customer decision, reassess that activity; the description “draft” does not determine its legal character.
Indonesian law adds a functional electronic-agent test. Article 21 allocates consequences of transactions through an electronic agent to its operator, subject to provisions concerning third-party interference, user negligence and proven force majeure or user fault. The parties must establish who operates the automated component. A connector-supply label cannot resolve that question. (Law No. 11 of 2008, as amended, arts. 1(8) and 21(2)–(5).)
For high-risk electronic transactions within the Indonesian provision, assess the electronic-signature and certificate requirement before enabling execution. Its explanation includes financial transactions conducted without physical face-to-face contact. Ordinary OAuth permission must not be assumed to meet that requirement. (Law No. 11 of 2008, art. 17(2a), inserted by Law No. 1 of 2024, and its Elucidation.)
Regulated duties follow the service and each party’s role
Establish the UK payment and outsourcing position
Start with the fintech’s regulated service and permissions. A technical-support exclusion under the payment rules requires the relevant conditions, including no possession of funds. Payment initiation and account information services are excluded from that exclusion. A provider cannot establish its position solely by saying it never holds money. (Payment Services Regulations 2017, Sch. 1, para. 2(j).)
Territory matters separately. FCA guidance generally places an overseas provider outside UK payment authorisation where it only supplies internet or similar services to UK customers from abroad. Establish the supplier’s actual presence and activity before applying that guidance. The UK fintech’s own obligations remain. (Payment Services Regulations 2017, reg. 138; FCA Handbook, PERG 15.5, Q39, and PERG 15.6, Q46.)
An authorised payment institution outsourcing payment-related operational functions must address notification and the conditions for important functions. It retains statutory responsibility for outsourced acts and omissions. Authorised electronic money institutions have corresponding outsourcing requirements. Banks and other firms require their applicable FCA and PRA rules to be mapped separately. (Payment Services Regulations 2017, regs. 25 and 36; Electronic Money Regulations 2011, SI 2011/99, reg. 26; FCA Handbook, SYSC 8.1; PRA Rulebook, Outsourcing, 1.1–1.2 and 2.1–2.1G.)
Payment service providers must also establish a framework of appropriate measures and controls to manage payment-service operational and security risks, with effective incident-management procedures. (Payment Services Regulations 2017, reg. 98(1).)
For firms within SYSC 15A, map the MCP dependency to important business services, impact tolerances and severe but plausible disruption testing. The mapping should include suppliers, credentials, approval services and recovery routes. These duties are not imposed on every business described as a fintech. (FCA Handbook, SYSC 15A.1.1R, 15A.2.1R, 15A.2.5R, 15A.2.9R, 15A.4 and 15A.5.)
The supply terms should therefore provide access to evidence, regulator cooperation, control over subcontracting, incident assistance and a workable exit. Existing statutory duties apply now. New FCA operational-incident and third-party reporting rules, and the revised PRA SS2/21, take effect on 18 March 2027. Build a dated update obligation into the contract. (FCA PS26/2; PRA SS2/21, November 2024 version and March 2026 future-effective version.)
Check Indonesian operation and financial-service boundaries
An Indonesian supplier operating an electronic service must assess private electronic-system registration before relevant use. Distinguish its operated service from bare software delivery. Registration does not authorise a payment activity. Electronic-agent operators also face identity, authorisation, access-control, transaction-integrity and continuity duties. (Government Regulation No. 71 of 2019, arts. 2, 6 and 36–40; Ministerial Regulation No. 5 of 2020, arts. 2–5, as amended by No. 10 of 2021.)
For payment functionality, assess Bank Indonesia’s current activity definitions, licence requirements and supporting-provider rules. PBI No. 10 of 2025 took effect on 31 March 2026. Supporting-provider status cannot be assumed where the supplier controls payment processing or accesses or administers sources of funds. Determine the actual service, territorial connection and allocation of control before allowing execution. (PBI No. 10 of 2025, arts. 10–11, 37, 62 and 65–70, including the Elucidation to art. 62.)
Critical and important supporting providers have a three-year registration transition, subject to Bank Indonesia’s implementation powers. This does not suspend all other applicable obligations during that period. (PBI No. 10 of 2025, art. 67(3), (6)–(7); PADG No. 32 of 2025, arts. 152–153 and 240.)
Map data access in both countries
Identify controllers, processors, subprocessors, purposes and locations. UK customer data accessed in Indonesia can engage Indonesian processing duties. A processor must follow instructions and obtain the required written permission for another processor. It cannot infer permission to train models or use customer data for its own purposes from a broad tool credential. (Indonesian Law No. 27 of 2022, arts. 2, 20 and 51–52; UK GDPR, art. 28.)
Where proposed processing is likely to pose high risk to individuals’ rights and freedoms, the UK GDPR requires the controller to complete a data protection impact assessment before processing starts, subject to its statutory exception. Assess Indonesia’s separate high-risk processing requirement where its law applies. (UK GDPR, art. 35(1), (10); Indonesian Law No. 27 of 2022, art. 34.)
UK hosting does not remove the international-transfer issue when a separate Indonesian supplier can access personal data remotely. Where the UK restricted-transfer rules apply, Indonesia has no UK adequacy coverage as at 29 October 2026. Assess an appropriate safeguard, commonly the UK International Data Transfer Agreement or EU clauses with the UK Addendum, and the current data-protection test. Map onward and return transfers separately under Indonesian law. (UK GDPR, arts. 44A and 46; ICO, International Transfers guidance; Indonesian Law No. 27 of 2022, art. 56.)
Separate proposal approval and execution
The fintech service owner should approve an authority schedule; the supplier should implement its assigned controls. The following design gives effect to the intended approval condition:
- Separate read, draft, record-write and payment tools. Issue distinct, limited credentials for the relevant systems and workloads. Check issuer, audience, tenant, resource and operation at the enforcement point.
- Keep approval outside the model’s discretion. Bind it to the authorised approver and exact account, recipient, amount, currency or record change. Include validity and single-use conditions. A changed proposal requires fresh approval.
- Apply account, value, frequency and permitted-recipient limits independently of the prompt. Any permission increase requires the designated authorisation route. Retrieved text and tool output cannot grant that authority.
- Keep secrets out of model context and ordinary logs. Protect access tokens, restrict downstream credentials and use appropriate expiry and refresh-token controls.
- Record the requesting identity, proposal, approver, policy and tool versions, approval time, execution identifier and result. Protect integrity and access. Set retention against actual obligations and investigation needs.
- Give the fintech an effective suspension route. Cover downstream credentials, refresh tokens, pending jobs and alternative execution paths. Test expiry, replay, wrong identity, changed parameters, duplicate requests and revocation.
These are proposed implementation choices. Relevant legal duties require appropriate security, authorisation, accountability and auditability; they do not prescribe these exact scope names or software components. Indonesian rules expressly address audit trails and electronic-agent controls. (UK GDPR, arts. 28 and 32; Government Regulation No. 71 of 2019, arts. 22 and 37–40.)
Execution should proceed only after the fintech confirms the service permissions and payer mandate, the parties settle their roles and data arrangements, and the implemented gate passes the agreed acceptance checks. A timeout must have a defined “outcome unknown” path: reconcile against the transaction record before any retry. Revocation blocks further use; it does not necessarily reverse an accepted payment instruction. (Payment Services Regulations 2017, reg. 83.)
Allocate incident response and financial loss
The contract needs a named incident lead for each party, immediate supplier escalation, evidence preservation and authority to stop action processing. Specify investigation access, factual updates, recovery decisions and reconciliation of payments and changed records. Preserve approval and execution records without retaining live credential secrets.
Notification rules have different triggers and recipients. A UK GDPR processor must notify its controller without undue delay. The controller must notify the regulator without undue delay and, where feasible, within 72 hours after awareness, subject to the statutory risk exception. High-risk breaches can also require notification to individuals without undue delay. (UK GDPR, arts. 33–34.)
Indonesia’s PDP Law requires the controller’s written notification within 3 × 24 hours to data subjects and the statutory institution. Article 46 does not expressly use the UK awareness trigger. Article 52 does not automatically impose that controller notification duty on every processor. Serious third-party-caused electronic-system disruption can separately require preservation and reporting at the first opportunity. (Law No. 27 of 2022, arts. 46 and 52; Government Regulation No. 71 of 2019, art. 24(3).)
Payment-service incident duties and applicable FCA notifications must also be assigned. A contract should require information early enough for each responsible party to meet its own deadline. Indonesia’s Government Regulation No. 33 of 2026 takes effect on 16 January 2027; the incident and transfer schedules need review before then. (Payment Services Regulations 2017, reg. 99; FCA Handbook, SUP 15.3.1R; Government Regulation No. 33 of 2026, art. 225.)
Allocate financial responsibility by cause and control. Address misconfigured permissions, absent approval checks, unauthorised supplier changes, compromised credentials, customer instructions and third-party attacks. Specify recoverable investigation, notification, restoration and transaction-correction costs; defence cooperation; insurance; liability caps; and any separately negotiated exceptions. Existing AI supplier contract coverage provides the wider agreement structure.
If a payment is unauthorised under the applicable UK rules, the payment service provider’s refund obligations cannot be replaced by a promise to pursue the MCP supplier. Recorded instrument use alone does not necessarily prove authorisation. Some larger business users can agree to disapply particular protections, including regulation 75; regulation 76 is not among those listed. Supplier recourse must be drafted alongside the payment-user remedies. (Payment Services Regulations 2017, regs. 63(5), 75–76.)
Choose governing law and dispute resolution expressly. For an agreement involving an Indonesian private entity and a foreign party, prepare coordinated Indonesian and English texts and agree the interpretive language. Check the mandatory Indonesian-law rule for specified international standard-form electronic contracts. An English-law clause does not displace Indonesian operating duties. (Law No. 24 of 2009, art. 31; Presidential Regulation No. 63 of 2019, art. 26; Law No. 11 of 2008, as amended, arts. 18 and 18A.)
The final allocation should match the authority schedule: who grants permission, who verifies approval, who executes, who preserves evidence and who can stop the system. Bring the tool inventory, approval flow, payment mandate and supply terms to Licentium to identify the required authority schedule, contract changes and conditions for deployment. Review agent permissions and supplier terms.