A Ghanaian merchant-software company proposes bank-account checkout for UK online merchants through its API. Can it supply the technology to an authorised UK payment initiation service provider, or should the group obtain its own permission? This hypothetical composite compares a provider-controlled redirect with a service that initiates orders under the Ghanaian company’s own merchant contract. Neither design holds payer funds. For the partner routes, the UK PISP is an authorised payment institution with PIS permission. The proposed arrangements are not a Licentium client engagement or a regulator-approved structure.
Executive Summary
- Launch a one-off, provider-controlled checkout pilot only after the contractual, operational and Ghana-related release conditions below are satisfied. The UK PISP should contract for payment initiation, control consent and send the instruction under its own bank-facing identity. The Ghanaian company should supply software and defined support services. (Payment Services Regulations 2017, S.I. 2017/752, regulations 25, 36 and 69.)
- Design A can support that allocation. Design B falls within payment initiation where the Ghanaian company accepts the payer’s request and undertakes to initiate under its own service contract. The technical-service exclusion expressly excludes payment initiation and account information; absence of fund possession cannot rescue an independently supplied initiation service. (PSRs 2017, regulation 2(1), Schedule 1, paragraphs 1(g)–(h) and 2(j).)
- UK authorisation also requires a territorial assessment. The FCA generally treats services supplied entirely from abroad by an overseas-incorporated and located provider as outside the UK authorisation requirement. That position does not confer UK PISP status or establish the statutory bank-access rights of an authorised provider. (PSRs 2017, regulations 69 and 138; PERG 15.6, Q46.)
- A UK group company should seek its own payment-initiation permission when the group intends that company to own the regulated service. It needs substantive UK operations, initial capital of €50,000 for PIS-only business, and professional indemnity insurance or a comparable guarantee. Small-payment-institution registration cannot cover PIS. (PSRs 2017, regulations 6(3)–(9), 14(4), Schedule 3, paragraph 2(1), table.)
- Third-party branding can accompany a licensed provider’s service, provided the provider remains the disclosed principal and controls initiation. Acting on that principal’s behalf in supplying payment services can instead require registered-agent treatment. A provider’s name in the footer cannot replace the correct legal and operational allocation. (PSRs 2017, regulations 2(1), 34 and 36; PERG 15.5, Q39.)
- Require a fresh permission assessment before the Ghanaian company takes independent authority to accept payer instructions or initiate them under its own obligation. Account-history access, reusable mandates, refund initiation, fund handling and changes in territorial presence require separate release reviews. (PSRs 2017, regulations 2(1), 67, 69–70 and 138, Schedule 1.)
The payment service at the checkout
Payment initiation is the central service in this proposal. Regulation 2(1) defines it by an online service initiating a payment order, at a user’s request, concerning an account held at another payment service provider. Schedule 1, paragraph 1(g), makes that a payment service. The definition does not require the initiator to receive the payment amount. A PISP must avoid holding payer funds in connection with its initiation service. (PSRs 2017, regulation 2(1), Schedule 1, paragraph 1(g), regulation 69(3)(a).)
In Design A, the UK provider performs PIS if it receives the payer’s request, controls the consent process and initiates the order. The payer’s account-servicing bank executes the credit transfer. The merchant’s bank receives the payment into the merchant’s account. An ordinary merchant receiving payment for its own goods does not become a payment service provider merely through that receipt. (PSRs 2017, Schedule 1, paragraph 1(c)(iii); PERG 15.3, Q18 and Q25b.)
The Ghanaian company can remain a software supplier where its button, bank selector and reporting support that provider’s service. Preparing an invoice or an unconsented payment intent does not, by itself, establish that the supplier initiates payment. The legal distinction depends on the service undertaken and performed, including who accepts the payer’s request. Labels in the API documentation cannot displace the actual allocation. (PSRs 2017, regulation 2(1), Schedule 1, paragraph 2(j); PERG 15.5, Q39.)
Design B crosses that functional boundary if the Ghanaian company undertakes to initiate the payment under its own merchant contract. On that condition, its online service acts on the payer’s request concerning an account at another provider. The UK partner’s later transmission to the bank does not necessarily remove the Ghanaian company’s initiation role. A merchant contract alone is insufficient to decide the issue: its promised service and the implemented consent sequence must match. (PSRs 2017, regulation 2(1), Schedule 1, paragraph 1(g); FCA, Payment Services and Electronic Money – Our Approach, May 2026, chapter 2, “Payment initiation services”.)
For an independently supplied Design B service, the Ghanaian company’s merchant and payer terms should identify its own initiation undertaking. It controls consent, transmits the instruction, receives the necessary initiation data and sets its service fee. Its own service desk answers payment complaints. The merchant remains responsible for goods refunds through its bank. A UK counterparty supplying the final connection does not discharge those contractual responsibilities merely by being authorised. Statutory responsibility depends separately on the applicable territorial rules. (PSRs 2017, regulations 2(1) and 138; PERG 15.6, Q46.)
Design B should not launch as an excluded software pilot on that allocation. Redesign it into a provider-controlled service, or assess an independent PIS route before making merchant commitments. Merely changing the contract heading to “technical services” would leave the functional issue intact. (PSRs 2017, Schedule 1, paragraphs 1(g) and 2(j).)
Payment-status messages and merchant reconciliation reports need not constitute account information services. The statutory AIS definition concerns online consolidated information about one or more payment accounts, provided to the user or another person on the user’s instructions. Adding account balances or transaction history for a separate reporting or risk product requires a new assessment. A PIS permission cannot serve as general permission to exploit bank-account data. (PSRs 2017, regulation 2(1), Schedule 1, paragraph 1(h), regulations 69(3)(f)–(g) and 70.)
The technical-service exclusion and the strongest contrary case
The technical-service exclusion has cumulative limits. It covers technical support for payment services without possession of the transferred funds, but expressly removes PIS and AIS from its scope. Data processing, authentication technology and communications can qualify when they remain supporting services. The exclusion fails when the supplier itself provides the excluded initiation or information service. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.5, Q39.)
The strongest argument against the software classification combines the merchant promise with the payer experience. The Ghanaian company sells bank checkout, presents bank selection, evaluates fraud, receives the payer’s action and causes the order to reach the bank. If it undertakes that initiation as its own service, calling the UK provider a backend processor changes no statutory element. This argument is particularly strong where Ghanaian staff can accept an instruction or determine its destination independently. (PSRs 2017, regulation 2(1), Schedule 1, paragraph 1(g).)
The answer must address that conduct rather than the location of a server. A PISP may outsource operational functions while remaining responsible for the service. Software can transport an instruction on the PISP’s behalf without its developer becoming an independent PISP. Provider-controlled consent, bank credentials, acceptance rules and release authority are evidence of that arrangement. None is an isolated statutory safe harbour. (PSRs 2017, regulations 25 and 36.)
A merchant’s software vendor supplies a commercial technology product. An outsourced service provider performs an operational function for the regulated firm. An agent acts on a payment institution’s behalf in providing payment services and requires registration before the principal uses it for those services in the UK. These categories can overlap across different tasks; ordinary outsourcing does not automatically create agency. An appointed-representative description cannot substitute for the PSRs agent route. (PSRs 2017, regulation 2(1), regulations 25, 34(1) and 36.)
The separate UK territorial assessment
Design B’s functional classification does not alone establish a UK authorisation breach. Regulation 138 concerns payment services provided in the United Kingdom. In PERG 15.6, Q46, the FCA generally places wholly overseas provision to UK customers outside that authorisation requirement. That guidance expressly considers internet provision from abroad. It is supervisory guidance, rather than an exemption that changes the statutory definition of PIS. (PSRs 2017, regulation 138; PERG 15.6, Q46.)
An offshore route therefore needs its own location-of-business assessment. The review must identify where staff accept instructions, where responsible management operates, and whether a UK establishment participates in supplying the service. UK merchant customers alone do not settle those questions. Nor does a Ghanaian permission satisfy the entry conditions for a UK authorised payment institution. (PSRs 2017, regulations 6(4)–(5) and 138; PERG 15.6, Q46.)
The recommended pilot should not depend on an offshore perimeter position. A foreign supplier cannot infer the statutory bank-access entitlement of a UK-authorised PISP merely from avoiding UK authorisation. Any alternative bank-access arrangement needs its own contractual and technical basis. The provider-controlled route gives the parties a defined regulated principal for the proposed UK service. (PSRs 2017, regulation 69(2).)
A narrow software contract with the UK PISP
For the first route, Design A should use a UK PISP-controlled checkout session. The merchant contracts with the PISP for initiation and separately with the Ghanaian company for merchant software. The PISP engages that company under an outsourcing agreement for the specified checkout and support functions. The payer buys goods from the merchant and accepts the PISP’s identified payment-service terms before requesting initiation.
The consent and instruction sequence starts with the merchant’s invoice details. The software sends those details to the PISP as an unconsented payment intent. The payer then enters the provider-controlled session, sees the payee and amount, and gives the required consent. The PISP identifies itself to the payer’s bank and sends the instruction. The bank performs the required authentication and executes the transfer to the merchant’s own bank account. A hosted redirect is a recommended control for this pilot, rather than a legal requirement for every PIS model. (PSRs 2017, regulations 43–44, 67, 69 and 100.)
For data, the PISP receives the bank response needed for initiation and returns a signed, limited status message. The Ghanaian company processes those messages on the PISP’s instructions for the outsourced service. It receives no bank-login credentials or independent access to account histories. Merchant order records and the supplier’s own software billing require separate controller-role allocations. The processing agreement must reflect those actual purposes. Payer information must remain within regulation 69’s recipient and purpose limits; GDPR compliance cannot authorise a wider disclosure. (PSRs 2017, regulation 69(3)(b)–(g); UK GDPR, Articles 5–6 and 28.)
The PISP sets its payment-service fee and contracts to collect it from the merchant. The Ghanaian company sets its separate software price and invoices the agreed outsourcing charge to the PISP. The pilot should charge the payer no separate initiation fee. Price-setting supports the stated commercial roles but cannot determine permission status by itself.
The merchant approves ordinary goods refunds and pays them through its own banking service. Ghanaian support staff may record requests and explain status, but receive no refund-initiation authority. Payment complaints go to the PISP, including complaints first received by its outsourced support team. The PISP retains responsibility for the outsourced service; supplier indemnities only allocate losses between the contracting businesses. Bank-facing statutory redress remains separate from the merchant’s returns policy. (PSRs 2017, regulations 36, 76, 93 and 101; DISP 1.6.2AR.)
A UK-authorised company within the group
The second route suits a group that intends to control and supply payment initiation itself. A UK group company should hold the PIS permission, contract with merchants and payers, and control the consent process. Its own bank-facing identity supports the instruction. The Ghanaian company supplies technology under an intragroup outsourcing agreement. Ownership of the software does not transfer the UK company’s regulatory responsibilities to its parent. (PSRs 2017, regulations 6, 25, 36 and 69.)
The UK company receives the bank responses, determines payment-service processing purposes and sets its payment fees. It handles payment complaints and carries the relevant initiation liability and insurance. The merchant still decides goods refunds; its bank executes them under separate authority. Ghanaian staff receive only the outsourced access assigned under the data and service agreements. This contractual allocation requires the UK company to exercise the stated powers in practice. (PSRs 2017, regulations 6(7)(e), 36, 69 and 93; UK GDPR, Article 28.)
The applicant must be constituted under UK law, with its head office and any registered office in the UK. It must carry on at least part of its payment-services business there. The FCA examines management, controls, the business plan and whether foreign close links impede supervision. A UK address coupled with all substantive payment decisions in Ghana would not satisfy the intended head-office arrangement. (PSRs 2017, regulation 6(4)–(9); FCA, Our Approach, May 2026, paragraphs 3.49–3.53.)
For PIS-only business, the initial-capital floor is €50,000. Capital must be in place before authorisation, and continuing capital requirements apply. Professional indemnity insurance or a comparable guarantee must cover the specified PIS liabilities in the relevant territories. A small pilot cannot use small-PI registration for PIS, and account-information-only registration does not authorise initiation. (PSRs 2017, regulations 6(3), 6(7)(e), 14(4), 17–18 and 22, Schedule 3, paragraph 2(1), table.)
This route is justified when ownership of the regulated merchant and payer relationship is part of the product strategy. It is unnecessary merely to preserve the group’s software brand. Licentium’s payment institution authorisation guide provides further reading on the application route.
A third-party-branded product under provider control
The third route can retain the Ghanaian company’s brand while the licensed provider supplies PIS. The merchant signs a direct PISP agreement or a tripartite contract that identifies the PISP’s undertaking. The Ghanaian company supplies the branded interface and software service. Before consent, the payer receives the PISP’s identity and accepts its initiation terms. A small “powered by” notice is inadequate if the surrounding contract promises the Ghanaian company’s own payment service. (PSRs 2017, regulations 2(1), 43 and 69.)
The provider controls the consent session, approved payee details, instruction rules and bank-facing credentials. Ghanaian software may display the approved interface or transmit provider-controlled messages. The PISP obtains the bank response; the Ghanaian company receives only the support data authorised under their processing agreement. The PISP sets or expressly approves the payment-service charge, while the supplier prices its software component. Bundled invoicing must identify those responsibilities without rewriting the underlying service.
The merchant controls commercial refunds. The PISP owns payment-complaint decisions and statutory initiation liabilities, even where the branded helpdesk receives the first contact. The provider must retain effective supervision, audit access and power to stop the service. These controls distinguish genuine outsourcing from a licensed firm lending its name to another company’s PIS. (PSRs 2017, regulations 25, 36, 76 and 93.)
If the Ghanaian company concludes payment-service contracts or accepts payer instructions on the principal’s behalf, assess registered-agent treatment before deployment. The principal must complete the applicable registration step before providing payment services in the UK through that agent. Agency disclosure and principal responsibility remain necessary. White-labelling alone neither proves agency nor dispenses with it. (PSRs 2017, regulations 2(1), 34(1), 34(16) and 36.)
Permission prerequisites and live-service controls
Before merchants receive a live service, the contracting PISP must hold the relevant permission without an incompatible restriction. The parties should match its legal name, register entry and bank-facing identity. An authorised PI relying on agents must have the required agent registrations. Insurance, applicable capital and the authorisation conditions require separate evidence; an integration agreement cannot supply missing permission. An applicant must also meet any applicable anti-money-laundering registration requirement. (PSRs 2017, regulations 6(8), 6–7, 22, 34 and 138.)
The PISP’s entitlement to use an accessible online payment account does not depend on a separate contract with the account-servicing bank. Secure identification, communication and authentication requirements still apply. The provider must complete the operational interface, certificate and testing work required for its chosen access method. Neither a commercial API subscription nor a directory entry is a substitute for regulatory status. (PSRs 2017, regulation 69(1)–(2); FCA, Our Approach, May 2026, paragraph 17.20.)
Payer consent and strong customer authentication perform different functions. The payer authorises the transaction under regulation 67; the relevant providers apply regulation 100 and the technical standards. Remote electronic payment authentication must meet the applicable amount-and-payee requirements, subject to permitted exemptions. Ghanaian fraud checks may inform the provider’s controls, but cannot unilaterally waive bank authentication. The pilot must preserve evidence of the consented amount, payee and instruction. (PSRs 2017, regulations 67, 75 and 100; FCA Technical Standards 2021, Strong Customer Authentication and Common and Secure Methods of Communication, Article 18.)
For this PIS-only pilot, neither fintech should collect customer funds. Regulation 69(3)(a) prohibits the PISP from holding payer funds in connection with initiation. If the group later receives relevant funds for another payment service, it must assess that service’s permission and safeguarding duties. Regulation 23 and applicable CASS 15 requirements then matter. Safeguarding a refund pot would not make fund holding permissible within PIS itself. (PSRs 2017, regulations 23 and 69(3)(a); CASS 15.1.1G–15.1.3R.)
Outsourcing brings operating duties even where the supplier needs no separate PIS permission. An authorised PI must notify the FCA of intended outsourcing of an operational function. Important outsourcing must preserve management responsibility, controls and effective supervision. Contracts should provide access to records, incident escalation, tested recovery and an executable exit plan. The UK principal remains responsible for outsourced acts and omissions. (PSRs 2017, regulations 25 and 36.)
The provider must maintain security-risk controls and handle reportable incidents. For an in-scope UK payment institution, operational-resilience rules require identification of important business services, impact tolerances and testing. A checkout outage or corrupted status feed belongs in that assessment. These are continuing operating obligations, although the firm must design a service capable of meeting them before launch. (PSRs 2017, regulations 98–99; SYSC 15A.1.1R, 15A.2, 15A.4–15A.5.)
Refunds, complaints and the payer’s information
Goods refunds should remain a separate merchant-controlled payment in the first product. The original payer’s consent cannot authorise a later debit from the merchant’s account. A refund API that initiates that debit introduces a new payer and consent sequence, even when the recipient is the original customer. The provider must assess that feature as an initiation service in its own right. (PSRs 2017, regulations 2(1), 67 and 69.)
For an unauthorised transaction, the payer’s bank has the refund obligation under regulation 76, subject to the applicable statutory conditions. Where a PISP is responsible, compensation between the bank and PISP follows the statutory allocation. Regulation 93 addresses non-execution and defective execution involving PIS. A merchant’s refusal to accept returned goods cannot determine those payment-service claims. (PSRs 2017, regulations 74–77, 93 and 95.)
The PISP should accept complaints directly and through the outsourced helpdesk. For complaints covered by the relevant DISP payment-service rule, the final-response period is 15 business days after receipt day. Exceptional circumstances beyond the firm’s control permit a holding response within that period. The final response must then follow within 35 business days after receipt day. Eligible complainants must receive the applicable Financial Ombudsman Service information. Other payment-service users remain within regulation 101’s complaint-procedure requirement where it applies. (DISP 1.6.2R(1)(d)–(f), 1.6.2AR and 2.7; PSRs 2017, regulation 101.)
The checkout must identify the actual PISP before initiation and supply the required transaction information afterwards. Marketing must describe the Ghanaian company’s software role without implying that it holds the partner’s authorisation. The provider’s communications must be fair, clear and not misleading within the applicable BCOBS scope. “Open banking licence” should be explained as shorthand for the permission required for the actual service. (PSRs 2017, regulations 43–44 and 139; BCOBS 2.1.3AR and 2.2.1R.)
For in-scope retail market business, the PISP must also apply the Consumer Duty. The product review should address customer understanding, support, price and value, and the design of the service. A branded interface should not obscure the provider’s identity or obstruct a complaint. Using a software distributor does not eliminate the regulated firm’s responsibilities across the distribution chain. (PRIN 2A.1.3G, 2A.1.7R, 2A.1.10G and 2A.1.13G–2A.1.15G.)
UK data duties and processing in Ghana
The contracts should assign the PISP’s payment processing to the correct controller and processor roles. Each controller needs a lawful basis, purpose limits, appropriate retention and privacy information. Payment consent does not automatically establish the UK GDPR basis for every fraud or reporting use. The processor contract must restrict instructions, subprocessors and use of the data. Security controls should limit staff access and record each support access. (UK GDPR, Articles 5–6, 13, 28 and 32; PSRs 2017, regulation 97.)
Each controller must provide a means for data subjects to complain about alleged UK GDPR infringements. It must acknowledge receipt within 30 days beginning when the complaint is received. Without undue delay, it must take appropriate steps to respond, including appropriate enquiries and progress updates, and communicate the outcome. The outsourced helpdesk should route complaints to the responsible controller and PISP. These duties do not extend the applicable payment-complaint deadlines. (Data Protection Act 2018, section 164A(1)–(5); DISP 1.6.2AR–1.6.2BR.)
A UK provider giving a separate Ghanaian processor remote access to personal data makes a restricted transfer even when the server remains in the UK. Ghana is not on the UK adequacy list. For the proposed routine outsourcing, the parties should use an appropriate Article 46 safeguard, normally the UK IDTA or applicable UK Addendum, with the required data protection test. The current test addresses protection that is not materially lower than UK protection. (UK GDPR, Article 46(1A), (2) and (6)–(8); ICO, International transfers guidance and Adequacy regulations.)
Independent Ghanaian processing that targets or monitors people in the UK needs a separate territorial assessment under Article 3. An Article 27 representative may be required where Article 3(2) applies and no exception applies. High-risk fraud profiling requires a data protection impact assessment before processing. (UK GDPR, Articles 3, 27 and 35; ICO, Data protection impact assessments.)
Fraud checks that make decisions with legal or similarly significant effects, without meaningful human involvement, engage the automated-decision rules. The controller must provide information about the decision and routes for representations, human intervention and challenge. Article 22B restricts decisions involving special-category data and prohibits sole automation where the decision-making processing relies wholly or partly on Article 6(1)(ea), the recognised-legitimate-interests basis. The parties should assess these conditions before enabling automated fraud refusals; a data protection impact assessment alone does not meet them. (UK GDPR, Articles 22A–22C.)
Ghanaian processing also engages the Data Protection Act, 2012 (Act 843). Sections 18(2) and 28–30 address foreign-origin data, security and processor arrangements. Section 45(1)(b) can reach a foreign controller using a processor carrying on business in Ghana. Section 45(2) then requires an overseas controller within that scope to register as an external company. Controller registration and the transit exception require separate attention. Active fraud analysis or customer support cannot be treated as mere transit. (Act 843, sections 27, 45–47 and 53.)
Ghana’s automated-decision rule requires a separate assessment. Subject to section 41(4), an individual can give written notice against a solely automated decision that significantly affects them. The controller also owes notification and reconsideration duties under section 41(2)–(3). The contractual exceptions concern decisions about entering into or performing a contract with the data subject; a merchant software contract alone does not establish that condition. (Act 843, section 41(1)–(4).)
The merchant-launch agreement should make Ghana clearance a separate condition precedent. The approval pack should address the company’s licence terms, overseas business, Ghana-based processing, outsourcing and any cross-border settlement. Payment-service permission in Ghana cannot replace UK authorisation where the UK entry conditions apply. The recommended pilot keeps merchant settlement in UK accounts and excludes foreign exchange and remittance features. (PSRs 2017, regulations 6 and 138.)
Minimum viable pilot and merchant-signing conditions
The first product should offer one-off sterling payments from online-accessible bank accounts to each merchant’s own UK account. Use one disclosed UK PISP, a provider-controlled consent session and a bank authentication flow. The Ghanaian API should create payment intents, display approved bank choices and return limited status messages. It should provide no account-history product, reusable mandate, refund-initiation API, wallet, collection account or settlement to Ghana.
The provider should approve the live consent screens and payment parameters, own the bank-facing credentials, and control production releases affecting initiation. Ghanaian engineers may operate the software under documented instructions. The provider should be able to revoke access and stop new initiations without the supplier’s commercial consent. Status handling must distinguish initiation accepted, bank processing and payment received; the merchant should not treat a button click as proof of cleared funds. These controls support the proposed outsourcing allocation. (PSRs 2017, regulations 25, 36, 44 and 69.)
Before signing merchants for live service, the parties should complete the following release pack:
- Obtain the PISP’s legal identity, permission record, restrictions, relevant insurance and any required agent entry. Match the service contract to those records. (PSRs 2017, regulations 6–7 and 34.)
- Execute the merchant, payer-facing, software and outsourcing terms. Attach the consent screens, fee schedule, complaint routing, refund limits and inter-business liability allocation. Preserve the principal’s statutory responsibilities. (PSRs 2017, regulations 25, 36 and 43–44.)
- Approve an end-to-end transaction trace showing who accepts consent, controls the payee and amount, identifies to the bank and sends each instruction. Include credential ownership, retry behaviour and release permissions. (PSRs 2017, regulations 67, 69 and 75.)
- Complete the Ghana approval pack with the licence certificate, conditions, approved business plan, variations and the required local clearances for the proposed operating model. Keep that decision separate from the UK technical-service analysis.
- Execute processing and international-transfer arrangements. Complete the data protection test, applicable Ghana registrations and any required impact assessment. Record support locations, subprocessors, retention and breach escalation. (UK GDPR, Articles 28, 32, 35 and 46; Act 843, sections 27–30 and 45–47.)
- Test bank integration, authentication, duplicate prevention, refunds outside the API, complaints and service recovery. Give the PISP approval authority over marketing and the operational release. (PSRs 2017, regulations 69, 98–100; SYSC 15A.4–15A.5; BCOBS 2.2.1R.)
Feature releases that reopen the permission decision
The decisive control change occurs when the Ghanaian company can accept the payer’s request and undertake initiation independently. That change requires a fresh service and territorial assessment before release, even when the payment path and absence of fund possession remain unchanged. A UK group entity intending to assume that role should obtain the relevant permission before providing the UK service. (PSRs 2017, regulations 2(1), 6 and 138, Schedule 1, paragraph 1(g).)
The release process should also stop for these changes:
- The supplier gains its own bank-facing initiation identity, accepts orders on its own terms, or controls consent independently. Reassess PIS, outsourcing and agency rather than treating the change as a technical migration. (PSRs 2017, regulations 2(1), 25, 34 and 69.)
- Account balances or transaction histories become a separate product, or the supplier reuses bank data for its own fraud service. Reassess AIS, the PIS data restrictions and controller purposes. (PSRs 2017, regulation 70, Schedule 1, paragraph 1(h); UK GDPR, Articles 5–6.)
- The product adds recurring or variable payments, reusable authorisations, independent retries or refund initiation. Reassess the scope of payer consent, authentication and payment-instruction authority. Existing permission does not approve every consent model. (PSRs 2017, regulations 67, 69 and 100.)
- A group entity receives collections, holds a refund pool, deducts fees from customer funds or introduces foreign-exchange settlement. Identify the additional payment service and its permission, capital and safeguarding duties before deployment. (PSRs 2017, regulation 23, Schedule 1; CASS 15.1.)
- Staff, management or instruction acceptance move into the UK, or processing moves to another country or subprocessor. Revisit territorial scope, the authorisation conditions, outsourcing and international transfers. (PSRs 2017, regulations 6, 25 and 37; PERG 15.6, Q46; UK GDPR, Articles 28 and 46.)
Each release should preserve a named regulated principal for the initiation step. Licentium’s regulatory-change monitoring can track selected regulator pages; the provider must still assess each product change against the operative rules.