Perimeter and home-state decision
We map the product, customer locations, fiat and crypto flows, custody, execution, outsourcing and cross-border plan to the exact HNB or HANFA service schedule.
Croatia - HNB and HANFA authorisation
Croatia MiCA CASP, PI and EMI Authorisation
SKY7 defines the right Croatian permission, designs the applicant and builds the governance, financial, safeguarding, technology and control evidence required for an HNB or HANFA application through one accountable workstream.
- 2 authorities
- HNB for PI and EMI; HANFA for the ordinary MiCA CASP route
- 3 routes
- Payment institution; electronic-money institution; MiCA CASP
- Tiered capital
- PI, EMI and MiCA capital follows the selected service scope and ongoing calculation
- EEA reach
- Full permissions use the relevant notification for each recorded service and target market
Choose the instrument before building the company
Croatia is commercially relevant for a founder who wants a euro-area base with direct access to the EU authorisation and notification framework. The product can require separate permissions: HNB authorises payment institutions and electronic-money institutions, while HANFA handles the ordinary MiCA authorisation for crypto-asset service providers. A product that combines accounts, wallets, card or transfer flows with crypto custody, exchange or execution can therefore need two coordinated perimeter decisions.
SKY7 begins with the customer journey and flow of funds. We identify who receives money, who records value, who holds assets or keys, who executes an order and which entity contracts with the customer. That map determines whether the core applicant should be a PI, EMI or CASP and whether an additional permission, regulated partner or product redesign is required.
Once the route is fixed, the Croatian company, management team, ownership, capital, providers and operating controls are built around the exact service schedule. The result is a business whose application, policies, forecasts, contracts and live technology all describe the same operating model.
Route selection
Which Croatian authorisation fits the product
| Route | Best fit | Authority and capital basis | Important boundary |
|---|---|---|---|
| Route Payment institution | Best fit Payment accounts, transfers, acquiring, payment instruments, remittance, payment initiation or account information. | Authority and capital basis HNB authorisation; initial capital follows the selected payment-service class of EUR 20,000, EUR 50,000 or EUR 125,000, with ongoing own funds. | Important boundary The decision covers the listed payment services. Electronic-money issuance follows the EMI route. |
| Route Electronic-money institution | Best fit Wallets or accounts that issue monetary value on receipt of funds, redeem it and support payments to parties other than the issuer. | Authority and capital basis HNB authorisation; statutory initial capital is at least EUR 350,000, with the applicable own-funds, safeguarding and payment-service requirements. | Important boundary Crypto custody, exchange, order execution and other crypto-asset services follow the relevant MiCA perimeter. |
| Route MiCA crypto-asset service provider | Best fit Crypto custody, platform operation, exchange, execution, placing, reception and transmission, advice, portfolio management or transfer services. | Authority and capital basis HANFA Article 63 authorisation; prudential safeguards use the EUR 50,000, EUR 125,000 or EUR 150,000 service class and fixed-overheads test. | Important boundary Providing payment services, operating payment accounts or issuing electronic money can add a separate HNB or regulated-partner workstream. |
| Route Eligible financial-entity notification | Best fit An already-regulated EU financial entity adding only the MiCA services permitted for its existing category under Article 60. | Authority and capital basis Notification to the authority allocated to the existing financial entity, supported by the required MiCA information. | Important boundary Eligibility and service equivalence are established instrument by instrument. An unregulated startup uses the Article 63 authorisation route. |
What SKY7 does
One accountable Croatian authorisation workstream
The scope is adapted to the selected permission and maturity of the applicant. SKY7 keeps commercial decisions and regulatory evidence connected from the first perimeter workshop.
Applicant and ownership design
We align the Croatian legal entity, group chart, qualifying holders, source of funds, board, senior managers and control functions with the proposed scale and risks.
Capital and financial model
We build three-year assumptions, initial and ongoing resources, stress cases and runway around the controlling PI, EMI or MiCA calculation.
Safeguarding or client-assets framework
PI and EMI work covers segregation, reconciliation and safeguarding counterparties; CASP work covers custody, client-asset records and access controls where applicable.
Governance and control library
We develop the required governance, AML/CFT, sanctions, complaints, conflicts, outsourcing, incident, continuity, DORA and wind-down records around named owners.
Filing and regulator follow-up
We coordinate the Croatian application set, evidence index, management preparation, submission record and responses through the authority's assessment.
Delivery sequence
From product map to an operating Croatian institution
The work proceeds through decision gates so capital and document production follow a viable regulatory design.
Stage 01 - Diagnose
Fix the Croatian perimeter
Map every product feature and flow to PI, EMI, MiCA, another regulated service or an outsourced partner and confirm the intended EEA markets.
The output is a service matrix, regulator allocation, dependency list and go-forward route.
Stage 02 - Design
Build the applicant and responsibility map
Set the company, ownership, management, local decision-making, capital, providers and implementation plan needed to support the selected route.
Named owners are assigned to each business, compliance, finance, risk, technology and operations deliverable.
Stage 03 - Evidence
Develop the regulator-facing file
Connect the programme, forecasts, policies, risk assessments, contracts, technology descriptions and implementation evidence into one indexed application record.
Each narrative is tested against the customer journey, funds flow and requested permission schedule.
Stage 04 - Assess
File, prepare management and answer the authority
Coordinate submission, management readiness and a controlled response process for HNB or HANFA questions and supplemental evidence.
Changes are reconciled across every affected document before a response is issued.
Stage 05 - Launch
Close conditions and complete notification steps
Confirm the final decision, register, approved services and reporting calendar, then coordinate the notifications required for each target market.
Safeguarding banks, schemes, liquidity providers and technology partners complete their own onboarding alongside the permission.
Application substance
What the authorities need to see in the operating model
A Croatian application is strongest when the customer proposition, money and asset flows, financial forecasts and control framework describe one implementable business. HNB expects a PI or EMI file to show the exact payment services, safeguarding method, own-funds calculation, governance, security, incidents, continuity, outsourcing and complaint process. An EMI must also explain issuance, redemption and the treatment of funds received for electronic money.
A HANFA MiCA file starts with the requested crypto-asset services and the service-class prudential safeguard. The evidence then follows the model: custody and key management, execution and order handling, pricing and exchange methodology, transfer controls, conflicts, client communications, complaints, outsourcing, ICT/DORA and wind-down as applicable. The management body and qualifying holders must be credible for the exact activities and scale.
Local substance is an operating question. The Croatian company needs real direction, accountable functions and access to its records and providers. Outsourcing can support the platform, but responsibility, oversight and contingency remain with the regulated applicant. SKY7 translates that principle into a practical responsibility matrix, board calendar, reporting architecture and implementation plan that can continue after authorisation.
Evidence map
Core work products by workstream
| Workstream | Core output | Route-specific emphasis |
|---|---|---|
| Workstream Business and services | Core output Programme of operations, customer journeys, jurisdictions, pricing, providers and implementation plan | Route-specific emphasis Payment-service schedule for PI/EMI; MiCA service and asset map for CASP |
| Workstream Finance and prudential resources | Core output Three-year model, capital and own-funds calculations, stress cases, funding evidence and runway | Route-specific emphasis PSD2/EMD method for PI/EMI; MiCA service class and fixed-overheads test for CASP |
| Workstream Customer money and assets | Core output Flow diagrams, reconciliations, account or wallet architecture, access and exception controls | Route-specific emphasis Safeguarding and redemption for PI/EMI; custody and client-asset records for relevant CASP services |
| Workstream Governance and people | Core output Organisation, role profiles, suitability evidence, committees, reporting lines and local responsibility matrix | Route-specific emphasis Skills and capacity matched to the payment, e-money or crypto service set |
| Workstream Risk and compliance | Core output Risk framework, AML/CFT, sanctions, complaints, conflicts, outsourcing, continuity and wind-down | Route-specific emphasis Payment fraud and security for PI/EMI; conduct, custody, execution or platform controls for CASP |
| Workstream Technology and DORA | Core output System architecture, ICT risk, access, change, incident, testing, third-party oversight and recovery evidence | Route-specific emphasis Critical service and data dependencies traced to the proposed live stack |
Commercial fit
When Croatia belongs on the shortlist
Croatia can fit a founder who wants a euro operating base, an EU permission and a business plan capable of supporting genuine local management. The HNB/HANFA split also makes the perimeter visible: payments and e-money have a dedicated central-bank route, while MiCA and the wider non-bank market sit with the financial-services authority. For a group building both fiat and crypto services, that can support a clear two-entity or partner-led architecture.
A commercially useful comparison goes beyond the headline permission. It covers management availability, salary and office assumptions, safeguarding and banking appetite, technology oversight, language and filing logistics, target host markets and the cost of maintaining one or two regulated entities. Banks, card schemes, exchanges, custodians and liquidity providers complete their own onboarding in parallel against the same operating model.
SKY7 turns that comparison into a decision memo before a full application mandate begins. If Croatia is the right home state, the memo becomes the foundation for the applicant and file. If another Member State or regulated-partner model is stronger, the founder can change direction before committing the larger part of the budget.
FAQ
Croatia authorisation questions
Discuss the product and target markets with the SKY7 team. Request an assessment
01 Do we need both a Croatian payment permission and MiCA authorisation?
It depends on the customer contract and flows. Crypto custody, exchange or execution sits in MiCA scope; providing payment services, operating payment accounts or issuing electronic money can create a separate HNB permission or regulated-partner workstream.
02 Can a Croatian PI issue electronic money?
A PI provides the payment services listed in its decision. Issuing electronic money uses the EMI route.
03 Can the Croatian permission reach other EEA states?
A full harmonised permission can use the applicable notification for the services recorded in the home decision. Each host-market plan still needs conduct, language, distribution and operational review.
04 Does SKY7 provide local directors or a safeguarding bank?
The mandate identifies the required roles and counterparties and can coordinate suitable workstreams. Appointment and onboarding remain subject to the candidate's, bank's or provider's own acceptance process.
05 Can we acquire an authorised Croatian company instead?
An acquisition can be assessed where a suitable target exists. The permission remains with the company, the proposed controller follows the applicable qualifying-holding process, and SKY7 coordinates verification of the regulatory and operating record before signing.
Reviewed by the SKY7 advisory team. Last reviewed: 18 July 2026. This service page is general information, not legal, regulatory, tax, investment or financial advice. Scope, capital, forms, fees, authority expectations and EEA notifications depend on the selected services and current rules. Authorisation and third-party onboarding outcomes remain with the relevant authority or provider.
Tell us what you need
Build the right Croatian authorisation file
Send the product summary, customer locations, fiat and crypto flows, ownership and target launch date. SKY7 will return a focused HNB/HANFA route and delivery scope.