Building a regulated fintech as a nineteen-year-old engineering student

I started building the company while studying engineering and reached the regulated registration stage at nineteen. That is unusual enough to attract attention, but age is not a substitute for a product, a control or a clear answer to a regulator's question.

The day-to-day work has been less cinematic than the headline. It has involved code, policy documents, bank connection testing, support wording, supplier checks, design revisions and repeated explanations of exactly what the product does.

Being young changes the context. It does not change the standard the service has to meet.

Engineering helped, but not in the obvious way

An engineering course teaches structured problem solving, assumptions, constraints and evidence. Those habits transfer well to software and regulated operations. A data flow can be mapped. A failure can be reproduced. A control can be tested against a defined risk.

The course did not teach me the Payment Services Regulations, privacy notices or how a principal firm assesses an agent. Those areas required separate reading, questions and review. Technical confidence can become a weakness when it creates the impression that every problem is solved by code.

A reliable API call does not explain the legal basis for storing the response. Encryption does not decide which member of staff needs access. A polished consent screen is not enough if its wording describes the wrong regulated firm.

Credibility has to come from the work

At nineteen, some conversations begin with an unspoken question about whether the company is serious. The only useful answer is evidence.

That means knowing the architecture, documenting decisions, responding to due-diligence questions directly and admitting when an answer needs checking. It means not using a title or an FCA reference number as a shortcut around the details.

The principal firm did not register an age or a pitch deck. It reviewed a company, its people, its service and the arrangements around it. The public register records the resulting agent relationship. It does not lower the operational expectations because the director is a student.

The work crosses disciplines quickly

A small regulated product does not have neat departmental boundaries. One change can touch interface copy, database fields, privacy documentation, monitoring and the principal firm's approval process.

For example, adding another type of account information is not only a new field on a screen. It raises questions about consent scope, retention, error states and whether support can explain what users are seeing. Removing a feature can require its own cleanup if old data or public copy remains.

I often move from TypeScript to a policy document and then to a test account at a bank. That range is useful for seeing the whole system. It is also mentally expensive, because each area has different language and failure modes.

Being the founder does not make every answer mine

There is a temptation in a small company to treat personal control as risk management. It is not. If one person holds every decision, password and explanation, the company has created a fragile dependency.

The principal relationship provides oversight for the regulated account information service. Specialist providers operate parts of the infrastructure. Official guidance defines many of the rules. The job is to understand those boundaries and keep evidence, not to pretend that one founder has replaced every professional discipline.

There are also moments when external review is necessary. Knowing that a question is outside my competence is part of operating responsibly. The difficult part is recognising that point before a confident assumption becomes a live feature.

Study and company work compete for the same attention

Course deadlines do not move because a bank feed fails. A product incident does not wait for an assignment to be submitted. Both kinds of work can be real at the same time.

I have had to treat time as a hard constraint. Some product ideas stay out. Some documents take longer. Some days are for university even when the company has an interesting problem. The result is not perfect balance. It is a sequence of deliberate trade-offs.

That constraint has influenced the product scope. A smaller service with clear limits is more credible than a broad roadmap that cannot be supported. The decision to use read-only account information, avoid payment initiation and keep the assistant as an optional feature all reduce unnecessary complexity.

The unglamorous part is the useful part

Registration is a milestone, but it does not finish the work. Policies need to match the system. Incidents need a route. Customer wording needs review. Access needs to be removed when a person no longer requires it. Dependencies need monitoring.

The same is true of the software. A launch version is not proof that categories will always be correct or every bank feed will be current. The product has to show limitations and provide ways to correct information.

I am proud of reaching this point, but the honest story is not that age made the company exceptional. The story is that a young founder still has to do ordinary, detailed work to a regulated standard, and has to keep learning where his own understanding ends.

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