What FCA agent registration actually involved, start to finish

Agent registration was not a single application form that I sent to the FCA. JEMA Software Ltd had to define its service, work with an authorised principal firm, complete that firm's due diligence and provide the information needed for the principal to register the company as its agent.

Finexer Ltd is the principal. It is authorised and regulated by the Financial Conduct Authority under the Payment Services Regulations 2017. JEMA Software Ltd is now listed as Finexer's Account Information Services agent.

The process had a beginning and a public registration date, but it does not have a clean end. The relationship brings ongoing controls, notifications and oversight.

First, define the regulated activity

The earliest useful question was not which form to fill in. It was what the product would actually do with a bank connection.

The app presents balances and transactions from accounts selected by a user. It organises that information into budgeting views. That is account information activity. The app does not initiate payments and JEMA Software Ltd does not hold client funds.

Writing that scope down exposed decisions that ordinary feature language could hide. A phrase such as manage your money might suggest actions that the service cannot perform. A roadmap item involving a payment would sit outside the chosen model. The regulatory description had to match the technical capability and public copy.

Then, choose the route

A company providing account information needs an appropriate regulated route. For JEMA, the route was to act as an agent of an authorised principal rather than seek a separate permission to provide the service in its own right.

That meant finding a principal whose infrastructure and oversight model fitted the product. The relationship could not be treated as a supplier contract for an API key. The principal would remain responsible for the regulated service provided through its agent and would need confidence in the company operating it.

Finexer provided the open banking infrastructure and principal relationship. Its own capabilities are broader, but the service JEMA presents is restricted to read-only account information.

Due diligence covered the company and its people

The review required information about JEMA Software Ltd, its ownership, directors, management and business model. It also required an account of the people responsible for the service and whether they were fit to manage the agent's activities.

This was not satisfied by saying that I could build the app. The questions reached experience, conduct, decision-making, financial position, company records and how responsibilities would be handled.

Accuracy mattered more than polished language. Where the company was small, the documents had to say so. Where a responsibility sat with a provider or principal, the boundary had to be explicit. A fictional department on an organisation chart would not create a real control.

The product and data flow had to be documented

We mapped the journey from a user choosing a bank through consent, bank authentication, data return, storage and display. The map identified which company handled each stage and which information crossed each boundary.

The review covered the data requested, why it was needed, where it was stored, how access was limited and what happened when consent ended. It also covered the distinction between disconnecting a bank and deleting historical data from an account.

Technical details had to agree with the customer explanation. If the policy said credentials stayed with the bank, the connection flow could not contain a product-owned password field. If the product was read-only, no payment action could be hidden elsewhere in the journey.

Policies needed operating steps behind them

Documents included areas such as information security, incidents, complaints, business continuity, access control, data protection and change management. Writing the document was only part of the task.

Each policy needed a practical owner and evidence. An incident process requires contact routes and escalation. Access control requires a list of who has access and a way to remove it. Change management requires someone to recognise when a feature affects the regulated service.

This was one of the harder parts for a small company. A policy copied from a large institution would describe committees and teams that did not exist. The process had to be proportionate without becoming imaginary.

Customer wording was part of the review

The product needs to identify Finexer as the authorised principal and JEMA as its registered agent. It also needs to explain consent, read-only access, complaints and the fact that bank credentials are not received by the app.

The wording cannot collapse into JEMA is FCA approved. That would hide the legal relationship and overstate the company's status. The exact disclosure now appears in the footer and open banking material.

The principal submitted the registration

Once due diligence and preparation reached the required point, Finexer submitted the agent details through the FCA process. The regulator's public register is the evidence that registration is complete.

JEMA Software Ltd appears under FRN 1061485. Finexer Ltd appears under FRN 925695. The entries can be checked directly rather than relying on a screenshot or marketing statement.

Registration did not certify the entire app or every future feature. It established the agent relationship for the regulated account information service described through the principal.

What happens after registration

Changes still matter. New data, altered consent, different providers, security incidents or changes to responsible people can require review or notification. The principal retains oversight and can request information or evidence.

The company also needs to keep public wording current, operate complaint routes and make sure the live product remains within scope. A registration entry is not a replacement for those controls.

The honest summary is that registration involved product definition, corporate due diligence, technical mapping, policies, customer communication and principal review. It was detailed because a bank-connected product handles information that deserves detailed questions. The process now continues through the way the service is operated.

For current service details, read the company's open banking explanation and Privacy Policy.