How to Assess Risk in Unregulated Fintech Companies

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Fintech describes technology-enabled financial services, not a single legal category. A fintech company may be fully autho­rised, regis­tered for a limited purpose, exempt from autho­ri­sation or operating unlaw­fully. Risk assessment should therefore begin with the exact service and legal entity rather than assuming that every unreg­u­lated fintech is dangerous—or that every regulatory badge provides the same protection.

Identify the service and regulatory perimeter

List what the company actually does: payments, e‑money, lending, investment, brokerage, account infor­mation, cryptoasset services, custody or software supplied to regulated firms. Record the customer country, contracting entity, domain, app publisher and every partner handling money or data.

Check the official register for the firm and the specific permission required for the service. The FCA’s guidance on checking whether a firm is autho­rised warns that a real firm can be cloned and that autho­ri­sation without the correct permission may leave consumers outside the expected Ombudsman or compen­sation protec­tions.

Distinguish authorisation, registration and exemption

A company may be regis­tered only for anti-money-laundering super­vision, act as an agent of another insti­tution or provide an unreg­u­lated technical service. These statuses are not inter­changeable. Identify the principal respon­sible for customers, who safeguards funds and which complaints route applies.

The FCA’s 2026 statement on unreg­u­lated Annex 1 firms explains that AML regis­tration is different from full autho­ri­sation and does not bring the wider conduct rulebook or Financial Ombudsman access. This illus­trates why inves­ti­gators must read the scope of a status rather than report simply that a company is “FCA regis­tered.”

Map custody, data and operational dependencies

Trace customer money from payer to settlement account and benefi­ciary. Identify the bank, e‑money insti­tution, payment processor, card network, cloud provider and outsourced compliance functions. Check whether customer money is safeguarded, segre­gated or covered by a compen­sation scheme.

Our guide to payment-service-provider risk helps map the opera­tional chain. Michael Schmitt’s analysis of payment ecosystem fragility and licensing adds practi­tioner context on sponsor-bank and infra­structure depen­dencies; legal conclu­sions must still follow the applicable permis­sions and primary records.

Test consumer and systemic risks separately

Consumer risks include misleading promo­tions, unautho­rised payments, weak complaints handling, data misuse, insol­vency and inacces­sible remedies. Systemic questions require evidence of scale, concen­tration, inter­con­nect­edness, corre­lated business models and substi­tution diffi­culty.

The Financial Stability Board’s fintech stability framework identified third-party opera­tional risk, cyber risk and monitoring of emerging macro­fi­nancial risk as prior­ities, while also stating at the time that it found no compelling systemic risk from fintech innovation as a whole. Inves­ti­gators should update that assessment with current size and depen­dency data rather than repeating either alarmist or reassuring claims.

Build an evidence-based decision

Create a matrix covering legal entity, permission, customer contract, funds protection, data access, outsourcing, complaints, financial condition and incident history. Test the product journey using lawful methods and retain screen­shots of every repre­sen­tation.

Malta Media’s report on regulatory restric­tions affecting Inpay’s iGaming onboarding is useful secondary context on how cross-border payment risk and customer-due-diligence expec­ta­tions interact, but the under­lying regulator findings should control any conclusion. The defen­sible question is not whether a fintech looks innov­ative or unreg­u­lated; it is which oblig­a­tions apply, who bears each risk and what remedy remains if the service fails.

Related Posts