What I would tell someone else trying to build a fintech

I am still early in building this company, so this is not a formula for success. It is a list of things I would want to hear before turning a financial product idea into a bank-connected service.

The advice is about building and operating software. It is not financial advice for the users of that software.

Write the regulated verb

Start by writing what the product does with an account. Does it read information, initiate a payment, hold money or perform another regulated activity? Avoid broad verbs such as manage until the underlying action is clear.

That sentence affects architecture, providers, permissions and public copy. If the product only reads account information, do not let a roadmap description imply that it can act on the account. If the sentence keeps changing, the product scope is not ready for a regulatory route.

Official FCA perimeter guidance is more useful here than another product's footer. Similar-looking apps can operate under different permissions and relationships.

Choose the regulatory route before the integration

An API demonstration can make bank connectivity look like a supplier choice. The regulated relationship underneath it matters just as much.

If the company will act as an agent, understand who the principal is, which service agreement applies to the customer, what oversight the principal performs and how product changes are reviewed. An agent reference number is not an independent authorisation.

Ask what happens during an incident and who handles a complaint. Those answers reveal more than a feature list.

Map the data before designing every screen

Draw the route from the user's action to the bank, provider, backend and interface. Include support, logs, analytics, backups and deletion. Mark which company controls each step.

For every field, record why it is needed. For every copy, record where it goes. For every provider, record the role and location described in the Privacy Policy.

This map will change. Keeping it current is easier than reconstructing it when a reviewer asks where a transaction description appears outside the main database.

Design the failed journey beside the successful one

A bank connection can expire, return incomplete data or fail during a redirect. A card transaction can remain pending. A merchant can be misidentified. A consent can be withdrawn.

Define what the user sees in those states before the polished success screen is finished. Include timestamps, retry boundaries and support information. A silent stale value is worse than an honest unavailable state.

Failure design also improves compliance. It prevents the interface from presenting old or partial account information as current certainty.

Clear the name early

A product name spreads into domains, app settings, legal copy, metadata, emails and internal identifiers. A later trademark conflict creates work in all of them.

Check the name before building a public identity around it. Use topic-based content URLs that can survive a rebrand. Keep company and product names separate in data models where they represent different things.

This is not only branding hygiene. Regulated disclosures need to identify the legal entity even when the consumer product name changes.

Do not invent a team in the policies

If the company has one person performing several roles, document that concentration. Do not write about a committee that does not meet or a department that does not exist.

Give controls a real owner, frequency and evidence. Record how access is reviewed, how an incident is escalated and how a release affecting regulated scope is approved.

A proportionate process can be simple. It cannot be fictional.

Treat content as part of the system

The website, app store copy, consent flow, support replies and legal pages all describe the service. They need to agree with the live product and regulatory role.

Search the whole repository when a claim changes. Static HTML, structured data and old generated pages can remain visible after the main component has been corrected. A stale sentence can create a false expectation even if no code path uses it.

Avoid outcome promises. Software can show data and calculations. It cannot guarantee what using them will mean for a person's finances.

Keep evidence as work happens

Retain test results, access reviews, decisions and provider checks in controlled locations. Do not rely on memory or a chat message that cannot be found later.

Evidence also makes the company less dependent on one founder. Another person can understand why a control exists and what the last review found without recreating the entire decision.

Protect the evidence itself. A screenshot containing account data is still account data, even when it sits inside a test report.

Be precise about what is not built

A clear exclusion can be valuable product information. This service does not initiate payments, hold client funds or receive bank credentials. Those statements tell a user and a reviewer where the boundary sits.

Do not keep every excluded feature as a vague future promise. Each one would bring new operations, support and risk. A narrow product that works inside a defensible scope is a stronger starting point than an all-purpose product whose responsibilities cannot be named.

Expect the work to continue

Registration is not the finish. Providers change, guidance changes, people change and the software changes. Reviews, incident preparation and public wording need to continue after the register entry appears.

The central lesson is simple: build the evidence and boundaries at the same time as the interface. Regulation will not make an unclear product clear. It will ask the questions that reveal the lack of clarity, usually after changing the answer has become more expensive.

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