Skip to main content

FCA regulatory perimeter & our position

Status: working analysis for the audit trail — not legal advice. It records our position and the verbatim wording it rests on, and marks the one point we will confirm with a UK payments lawyer before go-live. Grounded in the Payment Services Regulations 2017 (PSRs), the Electronic Money Regulations 2011 (EMRs), and FCA guidance. Verify each quote against the official source before it enters a regulatory filing.

Partner topology is not yet confirmed

Infinia is a middleware orchestrator sitting in front of more than one licensed partner. Working understanding: Keel Money Ltd is the UK (GBP), and possibly EU (EUR), e-money partner; the outbound BRL / PIX payout in Brazil is most likely a different Infinia partner. Confirming this map is action #1 — the position below is stated against it and shifts if it's wrong.

How the product works, and the money chain​

GrinGo is a point-of-sale travel app. A UK/EU user tops up a GrinGo balance in advance from their own UK bank (held as Keel e-money); at a Brazilian merchant they scan the merchant's PIX QR code and pay from that pre-loaded balance; any unspent balance is withdrawn back to their bank. Payments at the till come from the stored balance — GrinGo does not pull from the user's bank account per transaction (which matters for payment initiation).

The one fact that drives everything: GrinGo never possesses funds, never holds a key, never signs a payout. The licensed work is split across partners; GrinGo sits at the front as the app.

Our position​

GrinGo holds no client money and executes no payments, so it is not a payment institution or an e-money institution, and needs no authorisation of its own. Across the flow:

FlowWhat GrinGo isRegister?Basis
Load GBP/EURDistributor of Keel's e-moneyNodistributor definition; FCA Approach 5.5
Withdraw to own bankDistributor (redemption)NoEMRs reg 39; distributor definition
Pay merchant (PIX)An excluded technical service, or an agent of the executing partner — the one open pointNo if technical service; if agent, the partner registers usPSRs Sch 1 para 2(j); agent definition; FCA Approach 2.53

In plain terms: our expectation is that GrinGo itself appears on no FCA register, because the e-money legs are distribution and the merchant-payment leg is executed by a licensed partner rather than by us. That expectation is contingent on two things we will not simply assume: (1) the partner topology, and (2) a lawyer confirming the merchant-payment leg is a technical service and not agency. If it is agency, the executing partner must register GrinGo before go-live.

Why we are not a PI or EMI​

Both statuses hinge on receiving or holding funds, which we structurally never do.

  • We can't be the e-money issuer. Electronic money is "stored monetary value as represented by a claim on the electronic money issuer which — (a) is issued on receipt of funds…" (EMRs reg 2). The issuer is whoever receives the funds — that is Keel — and e-money "may not [be] issue[d]… through a distributor, agent or any other entity acting on its behalf" (EMRs reg 33(2)). We could not be the issuer even by intent.
  • We don't "provide a payment service." The prohibition is on "provid[ing] a payment service in the United Kingdom" without authorisation (PSRs reg 138). The regulated payment services — execution, money remittance, etc. (PSRs Schedule 1) — are performed by whoever executes them: Keel for the e-money legs, the payout partner for the merchant payment. Never GrinGo.

That we hold no client money is a design constraint, not just a description — see custody model.

Load and withdraw → distribution (no registration)​

The dividing line between the two unregistered/registered statuses is a single phrase in EMRs reg 2:

distributor — "a person who distributes or redeems electronic money on behalf of an electronic money institution but who does not provide payment services on its behalf" — no FCA registration; Keel merely identifies its distributors at authorisation.

agent — "a person who provides payment services on behalf of an electronic money institution" — must be registered by the principal before operating (EMRs reg 34: an EMI may provide payment services through an agent "only if the agent is included on the register").

Loading e-money is the paradigm distributor act — the FCA's own example is "a person who simply loads or redeems e-money on behalf of an EMI would, in principle, be considered to be a distributor" (FCA Approach Document, para 5.5). Withdrawing is redemption, a right owed by the issuer, not us: the issuer must "at the request of the electronic money holder, redeem — (i) at any time; and (ii) at par value, the monetary value of the electronic money held" (EMRs reg 39). On both legs we never receive the funds. These legs need no registration.

Pay-merchant leg → the one point we do not self-certify​

This leg most likely decomposes into a redemption out of the Keel balance (distribution, as above) followed by a cross-border payout executed by a separate partner. The payout itself is a regulated payment service — "money remittance" is "a service for the transmission of money… where funds are received from a payer for the sole purpose of transferring a corresponding amount to a payee" (PSRs reg 2) — but it is the partner's service, not ours. The FCA treats payment out of an e-money balance as bound up with issuance: "where a customer uses their e-money to pay a utility bill, this payment service would relate to the activity of issuing e-money" (FCA Approach Document, para 2.53).

Our own role is to relay an instruction and never touch the money, which fits the technical service provider exclusion:

PSRs Sch 1 para 2(j): "services provided by technical service providers, which support the provision of payment services, without the provider entering at any time into possession of the funds to be transferred, excluding payment initiation services or account information services."

But we do not treat that as settled — and here is the honest limit of the argument. Not touching funds is necessary but not sufficient for 2(j). The FCA reads the exclusion narrowly, for firms that "simply provide IT support… data processing or storage, authentication" (PERG 15.5, Q39) — back-office plumbing behind someone else's payment service. GrinGo is the consumer-facing brand: we onboard the customer, run KYC, hold the relationship and the ledger, and present the payment as ours. That profile pulls toward agent — "if… your activities amount to payment services you will need to consider whether you are required to be authorised or registered" (PERG 3A, Q22). So:

  • Custody is not the deciding line. Both technical service providers and agents are non-custodial. "We hold no money" defeats the PI/EMI and money-remitter characterisations — it does not by itself make us a technical service provider rather than an agent.
  • We plan for the agent outcome even though we argue for the exclusion. Providing a payment service without the right status is a criminal offence (reg 138); agent registration is cheap, ~2 months, and filed by the partner, not us. Given that asymmetry we hold go-live open for the legal opinion rather than self-certify the favourable reading.

Payment initiation — considered and excluded​

A point-of-sale "scan and pay" app invites the question: are we running a payment initiation service (PIS)? PIS is "an online service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider" (PSRs reg 2). It matters because PIS is regulated in its own right (full FCA authorisation), and is expressly excluded from the technical-service carve-out — para 2(j) ends "…excluding payment initiation services or account information services." If we were a PISP, the distributor / technical-service position could not save us.

We are not, on the current design, because there is no payment initiated on an account at another PSP:

  • At the till, the user pays from a pre-loaded Keel e-money balance — not from their bank account. The payment is a movement of our partner's e-money, not the initiation of a payment on the user's bank.
  • The top-up is a transfer the user pushes from their own bank (FPS/SEPA in). GrinGo does not initiate that payment on the user's bank account.

Design constraint (keep it this way): this conclusion holds only while top-ups are user-initiated. If GrinGo ever initiates the bank funding itself — e.g. an in-app "Pay by Bank" / open-banking pull from the user's account — that act is PIS, engaging a full authorisation outside the distributor/technical-service route. Any move toward open-banking top-ups is a regulatory-perimeter change, not just a feature.

The chain must hold — on both legs​

Our position only works if every link above us is licensed. Several checks are still open:

Territorial note — where the service is provided, not where the money lands​

The perimeter trigger is where the payment service is carried on, not where the funds settle: reg 138 prohibits "provid[ing] a payment service in the United Kingdom." Two consequences, and the second is a risk, not a comfort:

  • Brazil settlement does not make the activity "non-UK." Where money lands (Brazil) and where a service is provided are different questions. Transmitting money from the UK to a payee abroad is a textbook UK-regulated activity — that the destination is Brazil is the one-leg point, which changes which conduct rules apply, not whether the perimeter is engaged. GrinGo's own UK-facing activity stays in UK scope regardless of where the payout settles.
  • A non-UK payout partner shifts the concern — it does not make us the remitter. Whether the payout partner is inside the UK perimeter turns on where it is established and carries on business, not on the Brazil destination. Two things follow, and neither is the exposure you might first assume:
    • Money remittance requires "funds [to be] received from a payer" (PSRs reg 2). GrinGo never receives funds, so it cannot be the remitter on this leg either way — non-custody defends this squarely.
    • If the payout partner is offshore and outside the UK perimeter, there is no UK-authorised principal on that leg for GrinGo to be an agent of — so the agent-registration question may simply fall away for it. Offshore, if anything, lowers GrinGo's own registration exposure here.
    • The real cost of an offshore payout is elsewhere: is a UK-authorised firm actually standing behind that leg for our users (e.g. Keel paying out from the user's e-money, even if a Brazil partner operates the rail), or are UK users transacting with an unregulated offshore entity? That is a safeguarding, consumer-protection and AML question — and the FCA takes a dim view of UK-facing propositions routed through offshore unregulated entities. This is why the topology and the legal opinion matter here, not the mere fact of Brazilian settlement.

Verification checklist​

  • Map the topology (action #1) — get from Infinia, in writing, which partner does each leg: UK (GBP) e-money, EU (EUR) e-money, and the BRL/PIX payout.
  • Keel — confirm FRN 1020783 on the FCA register: entity name "Keel Money Ltd" (originally authorised 13 Aug 2021 as Frost Money), status "Authorised", permission to issue e-money. Confirm whether Keel also covers EUR. Screenshot for the file.
  • BRL/PIX payout partner — identify the entity, its jurisdiction, and its authorisation for cross-border payout / money remittance; verify on the relevant register.
  • Infinia — confirm it is a registered agent (or otherwise validly on the licence) of each partner it fronts.
  • Legal opinion — one written opinion on the pay-merchant leg: (a) excluded technical service vs agency, against the correct principal; and (b) since the payout settles offshore, whether a UK-authorised firm stands behind that leg for our users, or it is provided by a non-UK entity outside the perimeter (safeguarding / consumer-protection / AML implications). The single point we do not self-certify.
  • If agent — get the executing partner's written commitment to register GrinGo, with go-live conditional on that registration being live.
  • Contract — safeguarding of client funds (Keel's on the UK/EU leg; the payout partner's on the Brazil leg), governing law, and where our users rank on the insolvency of any entity in the chain.
  • Keep top-ups user-initiated — payments are from the pre-loaded balance and top-ups are pushed by the user from their bank, so no payment initiation arises. Revisit the perimeter before adding any open-banking / "Pay by Bank" top-up (that would be PIS — full authorisation).
  • Awareness — the FCA's March 2026 Approach Document update tightens principals' oversight of agent/distributor networks (exactly these BaaS stacks).

Sources​