FinTech Advisory
SK consult helps founders and teams to design fintech and payments models for cross-border markets—clear structure, compliant flows, and execution-ready documentation aligned with partners and regulators expectations.
Business model design
Payments route and partner strategy
Structure & flows (entities, geo, counterparties)
Onboarding readiness pack
Execution roadmap + optional support
A fintech model is a regulatory perimeter first and a product second
Almost every fintech that runs into trouble does so for the same reason: the product was designed first and the regulatory question was asked afterwards. By then the money flow is already built, the partner contracts are already signed, and the answer to "what exactly are we, legally?" has become expensive. The perimeter is not a compliance formality bolted on before launch. It determines which licence you need, which partners will touch you, where the money can sit, who is liable when a payment fails, and whether the business can be sold.
We work from the flow of funds outward. Who receives the customer's money, in whose name, into whose account, for how long, and on whose instruction — those five answers fix the regulatory classification more reliably than any description of the product. Once the perimeter is honest, everything downstream becomes tractable: the licensing route, the safeguarding model, the contract stack, the AML framework, the technology arrangements and the tax structure all follow from it.
SK Consult advises founders, scaling platforms and established groups building financial functionality across the EU and cross-border markets. We are not a product studio and we do not write code. We define what the business is allowed to be, what it has to be able to prove, and what has to be true before a regulator, a bank or an acquirer will engage with it.
What the engagement covers
Scope is set by where the business currently sits — an idea, a working product, or a licensed operation adding a new activity. The following components recur across almost every fintech mandate we run.
Regulatory perimeter analysis
The foundational question, answered in writing: is this activity regulated, in which member states, and as what. We map the model against payment services, electronic money issuance, crypto-asset services, credit provision, investment services and insurance distribution, and identify the exemptions that are genuinely available rather than the ones commonly assumed.
Flow-of-funds architecture
A diagram and a memorandum showing every account the money passes through, who holds legal title at each step, when settlement occurs and where client money begins and ends. This single document decides more regulatory outcomes than any other deliverable, and it is the first thing a supervisor or an acquirer's counsel will ask for.
Licensing route and sequencing
Comparison of the realistic paths: your own authorisation, appointment as an agent or distributor of a licensed entity, a banking-as-a-service arrangement, or a hybrid that starts partnered and migrates to owned. Each is costed against timeline, capital, substance and the commercial economics of the take rate you keep.
Contract and liability architecture
The full stack: user terms, merchant agreements, partner and BaaS contracts, processing and settlement terms, technology licences, data processing agreements and intra-group arrangements. Liability for fraud, chargebacks, failed payments, outages and regulatory breach is allocated deliberately rather than inherited from a template.
AML and CFT framework for a digital model
Business-wide risk assessment, onboarding and KYC design for remote and automated flows, sanctions and PEP screening, transaction monitoring rule sets calibrated to your actual product, reporting lines and the MLRO function. Built to work at your volumes rather than copied from a bank.
ICT, outsourcing and operational resilience
DORA-aligned ICT risk governance, the register of information on third-party providers, contractual clauses your cloud and processing vendors must accept, incident classification and reporting, exit strategies and testing obligations. Retrofitting this into signed vendor contracts is materially harder than negotiating it up front.
AI and automated decisioning governance
Where models score creditworthiness, price risk, screen customers or drive onboarding decisions, we assess classification under the EU AI Act, document the governance the regime expects, and align it with data protection obligations on automated decision-making. Model documentation is a regulatory artefact, not an engineering nicety.
Corporate, IP and tax architecture
Holding structure, where the regulated entity sits, where the intellectual property is owned and licensed, intra-group flows, transfer pricing exposure, and how the structure reads to an investor performing due diligence three years from now.
Partner, vendor and counterparty due diligence
Assessment and negotiation of the entities the business depends on: BaaS providers, acquirers, EMIs, custodians, processors and KYC vendors. Concentration risk, termination rights, pass-through obligations and what happens to your customers if the partner withdraws.
Who this is for
Pre-launch founders and product teams
Teams that need the perimeter fixed and the licensing route chosen before the architecture hardens and before investor diligence exposes a classification they cannot defend. This is the cheapest point at which the question can ever be answered.
Scaling platforms adding regulated activity
Businesses moving from a partnered model to their own authorisation, entering new member states, adding lending, cards, custody or foreign exchange, or replacing a partner whose risk appetite has changed. The existing structure has to be assessed honestly before anything is added to it.
Non-financial companies embedding financial features
Marketplaces, platforms, SaaS businesses and operators adding payments, wallets, payouts or credit to a product that was never designed as a financial service. The commercial-agent and limited-network exemptions are narrower than the market believes.
How the work runs
-
Model teardown
1–2 weeksWorking sessions on the product, the customer journey, the money flow, the counterparties and the commercial model. We reconstruct what the business actually does, which is frequently not what the pitch materials describe. Output: the flow-of-funds map and a first classification view.
-
Perimeter and route memorandum
2–3 weeksWritten analysis of regulatory classification by activity and jurisdiction, the exemptions available and their limits, the realistic licensing routes compared on cost, timeline and substance, and a plain statement of the issues that argue against the current design.
-
Architecture and documentation build
4–10 weeksCorporate structure, contract stack, AML framework, ICT and outsourcing documentation, governance and policy suite, and the evidence pack that will be put in front of a regulator, a bank or a partner.
-
Execution
2–9 monthsDepending on the route: authorisation application and supervisory dialogue, agent or distributor registration, partner onboarding and contract negotiation, banking and payment account opening, and the conditions that have to be cleared before going live.
-
Ongoing advisory
ongoingRegulatory change monitoring against your specific perimeter, new product and new market assessments, partner renegotiation, supervisory correspondence, and readiness for investor or acquirer diligence.
Timelines are indicative and assume the client is responsive on information requests. Where a route depends on a regulator or a partner institution, neither the outcome nor the timing is within any adviser's control.
The rules that currently shape fintech design
Fintech regulation in the EU is in an unusually dense period of change. Several of the rules below have already applied for some time, one has a deadline far enough away that most teams are ignoring it and will regret doing so, and one is still a draft that businesses keep designing towards. The dates matter more than the headlines.
What actually decides the outcome
Who holds the money, and for how long
Almost every classification argument turns on this. Funds that sit, even briefly, in an account controlled by the platform, in the platform's name, before onward transmission are the difference between an unregulated technology business and an unlicensed payment institution. Instantaneous pass-through and overnight holding are legally different facts.
Whether the model is honest about its regulated core
Businesses that describe themselves as pure technology providers while performing the economic function of a payment or lending business are the most common enforcement pattern in this sector. A supervisor assesses substance over description, and so does an acquirer's counsel.
The quality of the flow-of-funds documentation
A precise diagram supported by contracts that match it will move a licensing file, a bank onboarding and an investor diligence process faster than any other single artefact. A vague one signals to every reader that the business does not fully understand its own mechanics.
Whether the technology is owned or rented
A regulated entity that licenses its core platform from a related party, a founder-owned company or a single external vendor faces questions about outsourcing, control, continuity and transfer pricing. The answer affects licensing, DORA compliance and valuation simultaneously.
The regulatory history of the people involved
Fitness and propriety is assessed on individuals, not on the company. A prior refusal, a withdrawn authorisation, an adverse regulatory finding or an undisclosed directorship in another jurisdiction will surface. Disclosed early it is usually manageable; discovered by the supervisor it rarely is.
Timing against regime change
Launching into the closing months of a transitional period, or building against a draft regulation, converts a design decision into a deadline. Sequencing the project around the dates that actually bind is often worth more than any optimisation of the structure itself.
Where fintech projects go wrong
- Building the product first and asking whether it is regulated afterwards. By the time the money flow is live, changing the classification means rebuilding both the architecture and the contracts, usually under commercial pressure.
- Assuming the partner's licence covers you. An agent or distributor operates within a defined scope set by the principal and notified to the regulator. Activity outside that scope is unlicensed activity, and the liability does not sit with the partner.
- Treating "we are only a technology provider" as a legal position rather than a marketing line. It is a defensible characterisation for some models and an obviously false one for others; the distinction is factual and it is tested against the flow of funds.
- Using client money as working capital, or commingling it with operating funds. This is the fastest route from a regulatory problem to a personal one, and safeguarding failures are treated far more seriously than documentation failures.
- Designing to PSD3 and the PSR before they exist. The package is still in the legislative process; building compliance architecture against an unadopted draft produces work that has to be redone.
- Relying on a crypto transitional permission that expired on 1 July 2026, or on a partner whose MiCA status was never actually verified. Assumed authorisation is not authorisation.
- Signing cloud, processing and KYC vendor contracts without the ICT clauses DORA requires. Renegotiating an executed contract with a large provider, after the fact, from a position of dependence, is a materially worse negotiation.
- Running an automated credit or risk scoring model with no documentation of its data, its logic or its oversight. The obligation exists whether or not anyone has asked yet, and the documentation cannot be reconstructed convincingly after the fact.
What we typically need from you
The first substantive conversation is far more productive when the following are available. Nothing here needs to be polished — working drafts and internal documents are more useful than presentation material.
- A description of the product and the customer journey, including what the customer sees at the moment money moves.
- Any existing diagram of the flow of funds, however rough, and a list of every account the money touches.
- Corporate structure: entities, jurisdictions, shareholdings, and which entity contracts with the customer.
- Existing contracts with partners, processors, acquirers, banks, EMIs or BaaS providers, including schedules and annexes.
- Current user terms, merchant agreements and privacy documentation, if the product is live.
- Any regulatory correspondence, authorisation, registration or agent notification already in place, and any refusal or withdrawal in the group's history.
- Target markets by member state or country, and volumes — actual or projected — with average and maximum transaction sizes.
- Details of the technology arrangement: what is built in-house, what is licensed, and from whom.
- Information on the founders, directors and beneficial owners, including regulatory history and other directorships.
What drives the cost
Advisory work is quoted against defined deliverables once the model is understood. The variables below account for most of the spread between mandates.
- The number of regulated activities in scope. A single payment service is a contained analysis; payments plus credit plus crypto plus a card programme is four perimeters that interact.
- The number of jurisdictions. Classification is a member-state question as much as an EU one, and national interpretations of the same exemption diverge.
- Whether the business is pre-launch or already operating. Assessing a live model includes evaluating existing exposure and designing a remediation path alongside the target architecture.
- Whether a licensing application is included in the mandate or handled separately. Application work is scoped and priced as its own project.
- The volume of existing contracts to be reviewed and renegotiated, and whether counterparties are cooperative.
- The condition of the documentation you already hold. Complete and organised material shortens the work; reconstructing a contract history extends it.
- Third-party costs, which sit outside our fees: regulatory application and supervisory fees, audit and legal opinions where required, notarisation, apostille and translation.
Questions clients ask before starting
Do we actually need a licence, or can we use a partner?
Both are legitimate routes and the choice is commercial as much as legal. A partnered model launches faster and needs far less capital, but it caps the margin you keep, makes you dependent on the partner's risk appetite, and limits how the business is valued. Your own authorisation costs more and takes longer, but the licence is an asset. Many businesses correctly start partnered and migrate later — the point is to design the first version so that the migration is possible.
We are a marketplace, not a payment company. Does any of this apply?
Very possibly. The commercial-agent exemption relied on by most marketplaces is narrower than the market assumes, and it is interpreted differently across member states. Whether it holds depends on whether you act on behalf of the buyer or the seller, whether you have genuine authority to negotiate or conclude the sale, and whether funds settle through accounts you control. It is a question worth answering before volume grows, not after.
Can you build the product or integrate the APIs?
No. We are legal and structuring advisers, not a development shop. We define the constraints the build has to satisfy, review what has been built against them, and work alongside your engineering team or an external provider. We are usually most valuable in the room where architecture is being decided, before the code exists.
How much of this can wait until after launch?
The perimeter analysis and the flow-of-funds design cannot — they determine the build. The AML framework has to exist before the first customer is onboarded. Contract architecture should precede signing anything material. Ongoing monitoring and the resilience documentation can be phased. The general rule is that anything which would require rebuilding the money flow to fix belongs before launch.
Our investors are asking for a regulatory opinion. Is that what this is?
It can be part of it. A diligence-ready position typically means a written classification analysis, a documented flow of funds, evidence that the licensing or partnering route is sound, and a clear statement of open risks. We prepare that as a defined deliverable. What we will not do is issue an opinion that overstates the certainty of a position — an opinion that does not survive the acquirer's counsel is worse than none.
Is Cyprus the right place to base a fintech?
For some models it is a strong choice: EU authorisation with passporting, a supervisor with genuine experience in payments, investment services and crypto-asset services, an established professional infrastructure, and a competitive corporate rate even after the increase to 15 per cent from 1 January 2026. It is a poor choice if the plan is to hold a licence without building the substance the regime assumes. The right jurisdiction depends on your markets and your people, and we assess it rather than default to it.
What if our current setup is already non-compliant?
Tell us early and directly. Unlicensed activity, a lapsed transitional permission or a safeguarding failure is a serious matter, but it is a manageable one when it is addressed deliberately — assessed, contained, remediated and, where required, disclosed. It becomes far harder once a supervisor, a bank or a payment partner raises it first. We would rather begin with an uncomfortable fact than discover it mid-mandate.
Related services
This page describes SK Consult services and general practice. It is not legal or financial advice and does not create a client relationship. Financial services regulation is changing rapidly across the EU and several of the regimes referred to above are subject to ongoing legislative process; any decision should be taken on advice addressing your own circumstances.
Contact us
If you need practical legal and compliance support for cross-border operations, please get in touch with a brief overview of your business model, the jurisdictions involved, and your key counterparties—such as banks, EMIs, PSPs, or other partners. Based on that information, a proposed scope of work and recommended next steps can be provided.
Contact me
Ready to define the right next step?
Brief us on the objective, jurisdiction and current constraints.
