In Hungary, the fintech market has been consolidating over the past year: according to a report prepared by the regulator, the November 2025 FinTech and Digitalisation Report of the Hungarian National Bank (Magyar Nemzeti Bank – MNB), or “the MNB Report’, the number of new start-ups has decreased in the past two years, and several players have exited the market. Thus, the overall number of active domestic fintech companies has slightly decreased (to around 210). This suggests that after the previous “start-up boom”, the emphasis is increasingly on sustainable operations, order and revenue generation capacity, and co-operation with larger players. Financial software development and system integration, data analysis, and payment services are the main areas where domestic fintechs operate, which shows that many Hungarian fintechs operate principally as partners/suppliers of traditional financial players.

One of the characteristics of the Hungarian market is that due to the domestic size limit, foreign markets play a major role in growth: according to the MNB Report, 44% of the total sales revenue of the micro-SME fintech circle in the previous year came from exports, and nearly 30% of domestic fintech companies export. In addition, digitalisation has continued to strengthen on the banking side: according to a survey done by the MNB, the digital development of the domestic banking system further improved last year, while the use of artificial intelligence (AI) is also increasing.

Over the last 12 months, the digital transformation of the global financial sector was primarily driven by AI and fintech innovations. The MNB Report concludes that, globally, a structural reorganisation of the fintech ecosystem can be observed: the number of market participants has increased further on a global level and slightly decreased on a domestic level, while the volume of investments has fallen to a seven-and-a-half-year low. This process is the result of the high-interest-rate environment and the more cautious behaviour of investors. The strategic importance of digitalisation is demonstrated by the fact that the increasingly deeper embedding of AI technologies not only increases the efficiency of operational processes, but also offers a competitive advantage to pioneering companies. The change is also noticeable in business models: neobanks are increasingly generating profits, and a large part of the sector continues to be characterised by growth with losses. In Hungary, financial institutions are undergoing comprehensive digital modernisation, in line with international trends.

Nearly two-thirds of the companies in the domestic fintech sector operate in three service areas (financial software development and system integration, data analysis and payment solutions), and these are proving to be enduringly popular according to the MNB Report. For years, these service areas have covered the majority of the companies in the sector. The proportion of companies in the financial software development segment has expanded significantly, indicating that serving the development needs of domestic financial enterprises is of paramount business importance for the domestic fintech sector. Among micro and small enterprises in the sector, the share of the investment/financing and insurance segments has increased slightly, but the service area related to financial software development is still the most popular; this shows that domestic fintech companies often operate as partners and suppliers of the traditional financial sector. Micro and small enterprises also include the full range of companies dealing with blockchain and virtual currencies. In the case of medium-sized fintech companies, on the other hand, service areas related to cybersecurity and payment solutions are overrepresented.

As regards operating models, the scene is characterised by a symbiotic relationship where new players (start-ups) predominantly focus on B2B services, while legacy players (incumbent banks) focus on digitalising the customer experience through collaboration. The Hungarian market appears to be moving away from “neobank v traditional bank” competition towards a model where traditional banks adopt white-label fintech solutions (B2B) to maintain their dominant market position.

The predominant fintech business models/verticals in Hungary (according to public sources) are as follows.

B2B Fintech Solutions (Software and Infrastructure)

Over 80% of Hungarian fintechs operate in the B2B space, focusing on providing technology to financial institutions. Financial software development and systems integration is the largest sub-segment, including white-label apps and core banking modernisation. Data analytics and business intelligence is another major focus area, helping banks analyse customer behaviour and automate processes.

Payment Services and Digital Wallets (The Dominant Vertical)

This remains the most mature and widespread vertical, driven by the rise in cashless transactions and electronic payments. Mobile wallets (Apple/Google Pay) and instant payments are standard. Incumbent banks have fully integrated these services to stay competitive.

Lending Infrastructure and Buy Now, Pay Later (BNPL)

Fintechs are revolutionising the lending process, shifting away from long, paper-based applications towards digital, instant or white-label solutions. BNPL and digital factoring are growing rapidly for SME liquidity management. Local players are active in white-label lending/BNPL, digital factoring and B2B BNPL.

Regtech and Cybersecurity (Fraud Prevention)

As digital transactions increase, so too do cyber threats, making fraud detection a high-growth vertical. Key players focus on AI-powered fraud detection.

Open Banking and Banking as a Service (BaaS)

While the adoption of direct PSD2 API usage in Hungary is slower than in Western Europe, the groundwork has already been largely completed. This is a key area for new fintechs – both for open banking/BaaS providers and account information services.

In almost every vertical, the MNB is the key competent authority. Hungarian financial regulation is strongly activity-based: if a model falls into a regulated activity bucket, one will need an MNB authorisation/registration – or possibly authorisation from another European Economic Area (EEA)-based regulator (or must operate via a regulated partner and remain outside the regulated perimeter). The MNB maintains extensive licensing guides and a “fintech legal repository” within its Innovation Hub, which reflects this approach. Note that EU Regulations are directly applicable in Hungary (there is no transposition), but Hungary may adopt local procedural/penalty/supervisory rules around them. EU Directives require Hungarian implementing acts; local drafting choices can create edge cases where one must reconcile EU intent with Hungarian text and MNB practice.

Hungarian fintechs may use a wide range of compensation models – including flat or per-transaction fees, subscriptions, FX spreads, interest and late fees (for lending/BNPL), merchant-funded commissions, marketplace take-rates, investment management and performance fees, custody fees (including crypto) and referral or inducement payments. These models are generally permissible, but their legality and structure depend on the regulatory perimeter involved (payments, e-money, lending, investment services, insurance, crypto). In Hungary, most sectoral regimes are based on EU law – the Revised Payment Services Directive (PSD2), Markets in Financial Instruments Directive II (MiFID II), the Insurance Distribution Directive (IDD), the Markets in Crypto-Assets Regulation (MiCA) and the Consumer Credit Directive – and implemented or supervised locally by the MNB, which places strong emphasis on transparency and consumer protection.

Across sectors, the core requirement is clear, pre-contractual and ongoing disclosure of all costs and charges. For payment services, PSD2 requires ex-ante disclosure of fees, exchange rates and currency conversion margins, plus per-transaction breakdowns. For consumer credit and many BNPL models, Hungarian law (reflecting recent EU reforms) requires disclosure of the annual percentage rate/annual percentage rate of charge (APR/APRC), total cost of credit, instalment schedule and key rights before conclusion of the contract. For investment services, MiFID II mandates detailed ex-ante and ex-post disclosure of all costs and charges, including inducements and third-party commissions. Insurance distribution requires transparency regarding the remuneration structure, and crypto-asset services under MiCA require clear disclosure of fees and, in some cases, token-specific white papers.

Indirect remuneration (such as merchant commissions, referral fees, spreads embedded in FX rates or inducements in investment distribution) is generally allowed but must be transparent and, in regulated sectors, is often subject to additional conduct rules (eg, conflicts of interest management and annual ex-post reporting). In practice, Hungarian compliance depends less on which pricing model is chosen and more on whether the fintech correctly classifies its activity and provides sector-specific disclosures in the required format and timing, with the MNB actively supervising compliance and enforcing consumer transparency standards.

The short answer is that Hungarian fintechs are generally regulated by activity, not by status – meaning that if a fintech performs the same regulated activity as a bank (eg, deposit-taking, lending, payment services, investment services), it is subject to largely the same EU-derived sectoral rules, but often under a different institutional category (eg, payment institution instead of credit institution). Hungary follows the EU “same activity, same risk, same rules” principle embedded in frameworks such as PSD2, MiFID II, the Capital Requirements Directive (CRD)/Capital Requirements Regulation (CRR) and MiCA. The MNB acts as the integrated prudential and conduct supervisor for both legacy institutions and fintech firms.

That said, there are important structural differences in prudential intensity. For example, banks (credit institutions) are subject to the full CRD/CRR regime, including capital ratios, liquidity coverage (LCR), leverage ratio, recovery and resolution planning, and deposit guarantee participation. By contrast, fintechs authorised as payment institutions or e-money institutions face lower initial capital requirements and no deposit-taking licence, but must comply with safeguarding rules and operational requirements under PSD2 and Hungarian implementing law. In short, banks face broader and heavier prudential supervision; fintechs face more limited but still structured sectoral regimes tied to their licensed activity.

As regards conduct, transparency and consumer protection, fintechs and legacy players are regulated almost identically. Disclosure of fees (PSD2), APR in credit (Consumer Credit Directive), cost and inducement transparency (MiFID II) and crypto transparency (MiCA) apply regardless of whether the provider is a traditional bank or a digital-native fintech. However, fintechs may experience relatively greater supervisory focus on outsourcing, information and communication technology (ICT) risk and operational resilience under the Digital Operational Resilience Act (DORA), particularly where they rely heavily on cloud infrastructure or act as third-party providers. In practical terms, the main regulatory difference in Hungary is not lighter conduct rules, but rather that fintechs typically operate unlicensed or under narrower licences with lighter prudential burdens, while banks are subject to the full spectrum of systemic risk regulation.

Hungary does have a regulatory sandbox for fintechs, operated by the MNB as part of its Innovation Hub initiative. It is designed to provide a supervised test environment where eligible firms can experiment with innovative financial services, technologies or business models with real clients under defined conditions, while temporarily relaxing certain regulatory requirements to reduce barriers to entry and support practical validation of new solutions.

Under the Hungarian regulatory sandbox (Innovációs Pénzügyi Tesztkörnyezet – IPT), applicants start with a preliminary consultation with the MNB to clarify expectations and what compliance deviations might be needed. Firms then submit an application and – if accepted – receive a sandbox licence/approval enabling limited live testing with real customers for a defined period, with regulatory monitoring and joint evaluation at the end of the test phase. During the sandbox period, the MNB may grant temporary exemptions or simplified compliance from specific regulatory provisions (certain remote customer identification rules, elements of reporting obligations or internal process requirements), always with continued consumer protection and supervisory oversight.

In addition to the MNB, there is a regulatory body, the Supervisory Authority for Regulated Activities (SARA; Szabályozott Tevékenységek Felügyeleti Hatósága – SZTFH) for licensing crypto-asset exchange validation service providers, which CASPs must use in their business. The EU Commission has initiated an infringement procedure against Hungary for imposing additional requirements on CASPs

There is no publicly accessible register or specific MNB policy stating that applicants may seek legally binding comfort that the regulator will not enforce certain rules against them for a defined period if they proceed with an innovation. Available information about the MNB’s Innovation Hub and regulatory sandbox emphasises consultation and tailored supervisory support – but not formal no-action letters as a distinct regulatory instrument.

Instead, through the Innovation Hub platform, fintech firms can engage with the MNB to “ask the regulator” for regulatory clarity and get guidance on interpretation or compliance expectations for specific innovations.

In Hungary, regulated financial institutions (banks, payment institutions, investment firms, insurers, CASPs, etc) may outsource functions, including critical or important functions, but remain fully responsible for compliance. The MNB expects firms to conduct prior risk assessments and due diligence on the vendor, ensure ongoing monitoring, and maintain the ability to terminate and transition the service without disrupting operations.

Vendors themselves are not automatically regulated solely because they provide outsourced services, but they become subject to indirect regulatory obligations through contract and supervision. Mandatory contractual provisions typically include:

• clear description of services and service level agreements (SLAs);
• audit and access rights for the regulated entity and the MNB;
• data protection and confidentiality clauses;
• business continuity and disaster recovery obligations;
• sub-outsourcing controls;
• security requirements;
• incident reporting; and
• termination/exit and step-in rights.

The MNB must be able to access relevant data and premises where necessary.

It is not a legal requirement to outsource to a regulated entity, but in some cases it may reduce risk – particularly where the outsourced activity itself is regulated. Outsourcing to a regulated entity does not remove the primary firm’s responsibility, and the MNB will still supervise the outsourcing arrangement. In practice, firms choose regulated vendors where regulatory expertise, compliance infrastructure or passporting advantages are important; otherwise, robust contractual safeguards and oversight are essential.

In Hungary, fintech platforms are not automatically treated as “gatekeepers” in a competition law sense, but their regulatory responsibility depends on their functional role: if the platform itself performs regulated financial activities (eg, holding funds, initiating payments, granting credit, executing trades, providing investment advice or operating a crypto exchange), it is treated as a regulated service provider and must hold the appropriate licence and comply with all prudential and conduct rules. If it merely facilitates connections between users and licensed third parties without controlling the regulated activity, primary responsibility generally rests with the licensed provider, although the platform may still face obligations under consumer protection, disclosure, outsourcing and fraud prevention rules. In practice, Hungarian supervision focuses on substance over form – where a platform meaningfully controls or intermediates regulated functions, it is unlikely to be viewed as a neutral intermediary.

Significant MNB enforcement in fintech-relevant sectors has focused primarily on AML/CFT compliance, PSD2/open banking obligations and supervisory remediation orders. The MNB has imposed fines on major financial institutions for deficiencies in customer due diligence, screening systems and internal AML controls, signalling strict expectations that equally apply to licensed fintechs, including payment and CASPs. In the payments space, the MNB has also sanctioned institutions for failures to comply with PSD2 open-banking access requirements, demonstrating active enforcement of technical and data access obligations. Beyond monetary penalties, the MNB frequently issues corrective resolutions requiring firms to strengthen governance, risk management and compliance systems, underscoring a supervisory approach that combines financial sanctions with mandatory remediation across core fintech verticals.

In Hungary, non-financial regulations such as the General Data Protection Regulation (GDPR; privacy), cybersecurity rules (including DORA and national IT security requirements), consumer protection and EU digital platform rules apply to fintechs broadly the same as they do to legacy banks, but fintechs often face greater practical impact due to their digital-first models, heavy use of cloud and outsourcing, application programming interface (API) connectivity and reliance on online marketing. While banks typically have mature compliance and IT governance structures, fintechs must ensure that their software development, data monetisation, social media engagement and third-party integrations meet the same strict standards for data protection, incident reporting, resilience, transparency and auditability expected by Hungarian and EU regulators.

Beyond the MNB, Hungarian fintechs are reviewed by statutory external auditors (mandatory annual financial audits under Hungarian and EU audit rules), independent AML and compliance reviewers and, increasingly, ICT/cybersecurity assessors under DORA and national IT security requirements. Regulated entities must ensure independent testing of financial statements, internal controls, AML frameworks, and (where applicable) resilience and outsourcing arrangements, and auditors may have reporting obligations where material breaches are identified. In practice, larger or licensed fintechs typically engage established audit and advisory firms (often Big Four or specialist consultancies), while smaller or non-regulated firms face less formal scrutiny unless required by investors, banking partners or outsourcing clients.

In Hungary, fintechs often offer unregulated services (eg, analytics, rewards, marketplace features) alongside regulated ones (eg, payments, lending, crypto custody). These are structured either within the same licensed entity with clear contractual separation and disclosures, or through a separate affiliated entity to avoid regulatory spill-over. The MNB applies a substance-over-form approach: if an “unregulated” feature effectively performs a regulated activity, it may trigger licensing requirements. Regulators expect clear customer disclosure, segregation of functions and governance controls to ensure unregulated services do not undermine prudential, conduct or AML obligations.

No response has been provided in this jurisdiction.

In Hungary, AML and sanctions rules heavily impact regulated fintechs (eg, payment institutions, e-money issuers, lenders, investment firms, crypto providers), which are treated as “obliged entities” under the AML Act and must conduct KYC, beneficial ownership checks, transaction monitoring, suspicious activity reporting and EU sanctions screening, subject to MNB supervision and enforcement. Unregulated fintechs are not automatically subject to AML law, but in practice face an indirect impact through partnerships with regulated institutions, contractual compliance requirements, outsourcing controls and the risk of inadvertently triggering regulated status if they handle funds or facilitate transactions. As a result, AML and sanctions compliance significantly shapes product design and operations across the fintech sector.

In principle, Hungarian law (as a result of EU law implementation) recognises reverse solicitation, meaning that a regulated financial service may be provided cross-border into Hungary without triggering local licensing if the Hungarian client approaches the foreign provider on their own exclusive initiative. However, the concept is interpreted narrowly and cannot be used to circumvent domestic regulation. Historically, the local law approach is not solicitation based, and the concept of permitting reverse solicitation was adopted solely because of the force of EU law.

In practice, the cases where one can provide services to a Hungarian client on a true reverse-solicitation basis are limited; any active marketing, Hungarian language targeting, local presence or ongoing systematic business would typically trigger passporting or licensing requirements. The MNB applies a substance-over-form approach, and disclaimers alone are insufficient if the provider is effectively targeting the Hungarian market.

While robo-advisers do exist for Hungarian investors, the market is still developing rather than being dominated by large local players. Several global and European digital wealth platforms (eg, Revolut’s Robo-Advisor, available to users in Hungary) offer automated portfolio services through their apps, letting clients build and manage portfolios based on algorithms. Market reports also identify Hungary as a growing market for automated investment solutions, with increased interest in robo-advisory adoption among investors and expanding offerings over time.

In Hungary (as across the EU), different asset classes used in robo-advisory models can trigger different regulatory classifications and therefore different business models, depending on whether the assets fall inside or outside financial services regulation. The key distinction is whether the asset qualifies as a financial instrument (MiFID), a crypto-asset under MiCA or an unregulated asset. Each classification may require a different licence, capital framework, disclosure regime and supervisory relationship with the MNB, and robo-advisers must structure their business model accordingly.

In Hungary, legacy banks and investment firms typically implement robo-adviser solutions through hybrid models, combining automated risk profiling, model portfolios and algorithmic rebalancing with human oversight to meet MiFID II suitability requirements. Rather than launching standalone robo entities, they usually integrate white-label or in-house robo technology into existing online banking platforms under their current licences. Most banks integrate automated portfolio allocation tools, model portfolios and digital risk-profiling questionnaires into their existing private banking or retail investment channels. The robo component typically handles risk assessment, asset allocation and rebalancing logic, while a human adviser remains available for validation, complex cases or regulatory suitability confirmation – helping institutions remain aligned with MiFID II suitability and governance requirements. The focus is on digitalising advisory services, lowering costs and minimum investment thresholds, while retaining traditional compliance and supervisory structures.

In Hungary, robo-advisers that qualify as investment firms under MiFID II are subject to the same best execution obligations as traditional portfolio managers and brokers, meaning they must take all sufficient steps to obtain the best possible result for clients considering price, costs, speed, the likelihood of execution and settlement, size, the nature of the order and the avoidance of conflicts of interest. Hungarian-regulated firms must have a documented execution policy, disclose it clearly to clients, monitor execution quality and periodically review whether their routing arrangements achieve best execution in practice. The key regulatory focus is not the use of algorithms per se, but ensuring that automation does not weaken oversight, transparency or conflict management compared to traditional advisory models.

There are fintech lenders and digital lending solutions in Hungary, though the market is still emerging and is not as large as in some other EU countries. Several Hungarian fintechs offer digital financing products such as digital factoring, SME lending and BNPL platforms, and fintech service providers with lending-related infrastructure are active in the local market.

All fiat lending requires proper authorisation, but consumer lending is subject to extensive conduct and disclosure rules, SME lending is moderately regulated with fewer mandatory form protections, and large corporate lending is primarily governed by prudential supervision and contract freedom rather than borrower-protection law.

In Hungary, underwriting is generally risk-based and increasingly automated. Consumer lenders typically check credit bureau data (Központi Hitelinformációs Rendszer – KHR), verify income, assess debt levels and run internal scoring models. Fintech lenders often use digital tools, including transaction data and automated decision engines, to speed up approvals. For SMEs and corporates, the focus is more on financial statements, cash flow, business performance and collateral.

Regulation does not dictate the exact scoring model, but it does require lenders – especially in consumer lending – to assess creditworthiness responsibly and document their decision. Banks face additional internal risk management and capital requirements, while fintechs have more flexibility in how they design their models, as long as they assess risk properly and comply with consumer protection and data rules.

The key distinction is whether lenders fund loans themselves or merely provide technology and servicing infrastructure.

If the fintech originates and funds the loans on its own balance sheet, it must be licensed in Hungary as a credit institution or financial enterprise and fund lending through equity, shareholder loans, bank credit lines or institutional investors. It cannot take deposits from the public unless it holds a banking licence. If it offers BNPL to consumers, consumer credit rules (including creditworthiness assessment and disclosure) apply. If it structures merchant-funded BNPL (where the merchant subsidises the cost), it must ensure the model does not inadvertently qualify as unauthorised deposit-taking or collective investment activity (Hungary is updating its regulatory approach to BNPL to align with the EU’s new Consumer Credit Directive, so that most deferred-payment products will be treated as regulated consumer credit unless they meet narrow short-term exemptions – these changes are expected to take effect from 20 November 2026).

By contrast, where a company operates as a white-label technology provider, and the actual lender is a licensed bank or financial enterprise, the fintech typically does not fund loans itself. Instead, it earns service fees while the regulated lender provides capital and bears credit risk. In this model, the regulatory burden (capital, lending licence, AML obligations as lender) sits primarily with the licensed financial institution, while the fintech is subject mainly to outsourcing, data protection, ICT and contractual compliance requirements. The regulatory risk therefore turns on whether the fintech is acting as lender, co-lender or pure infrastructure provider.

In Hungary’s fintech space, one does not typically see large-scale retail P2P-style syndicated consumer lending platforms like in the UK or USA. Institutional funding and risk participation structures may occur. True retail syndication could also trigger crowdfunding or investment regulation and is therefore uncommon in the Hungarian fintech market.

In Hungary, payment processors are not legally required to use only existing payment rails (eg, card schemes, Single Euro Payments Area (SEPA), domestic clearing systems), but in practice they must operate within the framework of recognised payment systems and regulatory approval.

If a fintech is licensed as a payment institution or e-money institution under PSD2, it may design innovative payment flows, but when funds move through the banking system, they must ultimately connect to recognised payment infrastructures (such as SEPA credit transfer, instant payment systems or card networks). Access to these systems typically requires either (i) participation as a credit institution or (ii) indirect access via a sponsoring bank.

Creating an entirely new “payment rail” (ie, a new payment system or clearing and settlement system) is legally possible but would require compliance with EU and Hungarian rules on payment systems and settlement finality, and potentially authorisation as a system operator, with oversight by the MNB and, depending on scale, the European Central Bank. In practice, this is complex and capital-intensive, so most fintechs innovate at the application layer while relying on existing regulated infrastructures for clearing and settlement.

In Hungary, cross-border payments and remittances are regulated under the EU PSD2 framework (as implemented in Hungarian law), meaning providers must be licensed as a payment institution, e-money institution or credit institution, or act as an authorised agent. Within the EU, services may be provided through passporting; outside the EU, local licensing or a compliant cross-border structure is generally required. Providers must also comply with transparency rules on fees, FX margins, execution times and safeguarding of client funds.

The main regulatory focus areas are AML/CFT and sanctions compliance, which are particularly strict for cross-border flows. Firms must conduct customer due diligence, apply enhanced checks for high-risk jurisdictions, monitor transactions, screen against EU sanctions lists and report suspicious activity to the Hungarian Financial Intelligence Unit (FIU). The regulator also focuses on fraud prevention, consumer protection, operational resilience (including ICT risk under DORA) and proper handling of correspondent banking and third-country risk exposure. In practice, AML and sanctions controls are the most compliance-intensive aspects for cross-border remittance providers.

In Hungary, the permissible type of marketplace or trading platform depends on what is traded and how the platform operates, with different regulatory regimes applying.

• Financial instrument trading platforms (securities, derivatives, security tokens): Platforms trading financial instruments fall under MiFID II/MiFIR and must be authorised as a regulated market, multilateral trading facility (MTF), organised trading facility (OTF) or investment firm. This involves MNB licensing, capital requirements, conduct rules and market transparency obligations.
• Crypto-asset trading platforms: Crypto exchanges fall under MiCA and must be authorised as CASPs. If the crypto qualifies as a financial instrument (eg, a security token), MiFID II applies instead.
• Payment and e-commerce marketplaces: General marketplaces are unregulated unless they hold funds or process payments, in which case PSD2/e-money rules apply unless a narrow exemption is available.
• Crowdfunding platforms (lending or investment-based): Business lending or investment platforms fall under the EU Crowdfunding Regulation (ECSPR) and require specific authorisation, investor disclosures and governance safeguards. This regime is lighter than MiFID but still supervised.
• P2P lending marketplaces: These may fall under ECSPR, lending regulation or securities law depending on the structure – particularly whether funds are pooled or interests are transferable.

Overall, classification depends on substance, and the MNB determines the applicable regime based on the platform’s actual role.

In Hungary (in line with EU law), different asset classes are subject to different regulatory regimes, and classification is decisive.

• Traditional financial instruments (shares, bonds, exchange-traded funds (ETFs), derivatives): These fall under MiFID II/MiFIR and related EU frameworks. Firms providing brokerage, trading, custody or advice must be licensed as investment firms or credit institutions and comply with capital, conduct, best execution, market abuse and disclosure rules.
• Security tokens (tokenised financial instruments): If a token qualifies as a “financial instrument” (eg, transferable security) under MiFID II, it is regulated in the same way as its traditional equivalent. Tokenisation does not change the regime; MiFID, Prospectus Regulation and market abuse rules apply.
• Crypto-assets that are not financial instruments: These fall under MiCA. Service providers (exchanges, custody, advice, execution) must be authorised as CASPs and comply with governance, conduct, capital and disclosure requirements. Issuers of certain tokens (eg, asset-referenced tokens or e-money tokens) face additional obligations.
• E-money tokens (stablecoins referencing a single currency): These are regulated under MiCA but aligned closely with e-money rules, often requiring issuance by a credit institution or authorised e-money institution, with safeguarding and redemption rights.

In short, the key question is whether the asset qualifies as a financial instrument (MiFID) or a crypto-asset under MiCA. The regulatory consequences (licensing, capital requirements, disclosures and supervision by the MNB) differ accordingly.

The emergence of cryptocurrency exchanges has significantly reshaped regulation in Hungary, primarily through the implementation of MiCA. Under MiCA, centralised crypto exchanges operating in Hungary (or targeting Hungarian clients) must obtain authorisation as CASPs and comply with conduct, governance, capital, custody, complaints-handling and market abuse prevention requirements, AML/CFT and EU sanctions screening obligations, etc.

For decentralised exchanges (DEXs), regulation is more complex. MiCA generally applies to identifiable legal or natural persons providing crypto-asset services “in a professional capacity”. Fully decentralised protocols without a central operator may fall outside direct authorisation requirements, but where there is a controlling entity, governance body or frontend operator facilitating access, regulators may treat that party as a service provider subject to MiCA.

In the Hungarian fintech context, “listing standards” depend on what is being listed.

Regulatory Listing Standards

If securities (including security tokens qualifying as financial instruments) are listed or admitted to trading on a regulated market or MTF, the issuer must comply with the EU Prospectus Regulation, MiFID II/MiFIR venue rules, and the Market Abuse Regulation (MAR), including publication of an approved prospectus (unless an exemption applies), ongoing disclosure of inside information, periodic reporting and corporate governance requirements. For crowdfunding platforms under ECSPR, issuers must publish a key investment information sheet (KIIS) rather than a full prospectus (within thresholds). For crypto-asset exchanges, MiCA requires the publication of a compliant crypto-asset white paper (for in-scope tokens) and imposes due diligence and disclosure obligations before admission to trading. AML/sanctions screening also forms part of listing controls for platforms.

There are no formal, binding industry-wide listing standards specific to the Hungarian fintech sector beyond what is required by EU and Hungarian law.

Order handling rules apply in Hungary where a fintech provides regulated investment services under MiFID II. Firms receiving, transmitting or executing client orders must comply with best execution, fair and prompt order handling, transparent execution policies, proper order allocation, conflict management and record-keeping requirements. Similar (though separate) conduct standards apply to CASPs under MiCA. If a platform does not perform regulated order execution activities, these rules do not apply, but classification is based on substance rather than form.

While P2P-style trading and lending experiences exist for Hungarian users, most operate within regulated frameworks (ECSPR/MiCA/MiFID) rather than as informal or unlicensed peer-to-peer networks.

Payment for order flow (PFOF) is heavily restricted in Hungary and through the EU. Under MiFID II inducement and best-execution rules, investment firms must act honestly, fairly and professionally in the best interests of clients and take all sufficient steps to obtain the best possible result. PFOF creates an inherent conflict of interest between execution quality and broker remuneration. In practice, several EU supervisors – and European Securities and Markets Authority (ESMA) guidance – have treated PFOF as incompatible with best execution and inducement rules for retail clients. The EU has now moved towards an effective ban on PFOF for retail order flow under the Retail Investment Strategy reforms (with limited transitional arrangements in some member states). As a result, Hungarian investment firms supervised by the MNB generally cannot rely on PFOF as a core revenue model for retail trading.

This significantly affects commission-free trading apps and robo-brokers. Unlike in the USA, Hungarian/EU fintech brokers cannot typically fund “zero-commission” models through PFOF arrangements. Instead, they rely on transparent commissions, FX spreads, subscription fees, securities lending or other disclosed revenue streams. Any execution arrangements must be documented in an execution policy, conflicts must be managed and remuneration structures must not impair compliance with best execution.

For crypto-asset trading under MiCA, similar conflict-of-interest and fair pricing standards apply, although the legal framework differs from MiFID.

In Hungary, trading in financial instruments is governed by the MAR, which applies directly and is enforced by the MNB. The core principles are to ensure fair, transparent and orderly markets and to prohibit conduct that distorts price formation or exploits non-public information. The main prohibitions are:

• insider dealing – trading (or attempting to trade) while in possession of inside information;
• unlawful disclosure of inside information – ie, improperly sharing price-sensitive, non-public information; and
• market manipulation – engaging in transactions or disseminating information that gives false or misleading signals as to supply, demand or price.

Issuers whose instruments are admitted to trading must also comply with ongoing disclosure obligations, including prompt publication of inside information (unless validly delayed), maintenance of insider lists and reporting of managers’ transactions. Investment firms and trading venues must have monitoring and reporting systems in place.

For crypto-assets, MiCA introduces a parallel market abuse regime for in-scope tokens admitted to trading on crypto platforms, applying similar insider trading and market manipulation prohibitions adapted to the crypto environment.

In Hungary, high-frequency and algorithmic trading in financial instruments is regulated under MiFID II, which contains specific rules for firms engaging in algorithmic trading. Investment firms using algorithmic systems must have robust governance, risk controls, pre-trade limits, real-time monitoring, kill switches and testing procedures to prevent disorderly markets. Firms engaged in high-frequency trading (HFT) techniques must notify the regulator (MNB), maintain detailed records of algorithms and order data, and ensure systems are resilient and capacity-tested. Trading venues must also have circuit breakers and monitoring systems in place. These obligations apply regardless of whether the trader is a traditional bank or fintech firm.

Different asset classes are subject to different regimes. For traditional financial instruments (shares, bonds, derivatives, ETFs and security tokens qualifying as financial instruments), the full MiFID II algorithmic trading framework applies. For crypto-assets, MiCA does not replicate the detailed MiFID HFT regime, but it imposes general conduct, systems resilience and market abuse controls on CASPs operating trading platforms. Fully decentralised trading protocols without an identifiable operator may fall outside direct authorisation requirements, though market abuse and AML concerns remain relevant. In short, algorithmic trading in regulated securities markets is tightly governed under MiFID II, while crypto trading is subject to a lighter but developing regime under MiCA.

In Hungary, a firm engaging in high-frequency or algorithmic trading in a principal (own-account) capacity does not need a separate “market-maker licence”, but it will typically need to be authorised as an investment firm or credit institution under MiFID II, unless a specific exemption applies. Dealing on own account as a business is itself a regulated activity.

Where a firm performs formal market-making on a regulated market, MTF or OTF (ie, providing continuous liquidity under a venue agreement), it must comply with the venue’s market-making rules and MiFID II organisational, capital and risk-control requirements. Firms using algorithmic or HFT techniques must notify the MNB, implement robust pre-trade controls, monitoring systems and kill switches, and maintain detailed records of their algorithms and orders.

In short, there is no standalone market-maker registration regime, but principal HFT activity generally requires full investment firm authorisation and compliance with enhanced governance and risk standards.

Hungarian and EU regulation distinguishes between funds and dealers (investment firms) engaging in HFT or algorithmic trading, even though both may use similar technologies.

Dealers/investment firms trading on own account (including HFT strategies) fall directly under MiFID II. Dealing on own account is a regulated activity, requiring authorisation as an investment firm or credit institution (unless a narrow exemption applies). These firms are subject to detailed organisational, capital, best execution, market conduct and algorithmic trading controls (eg, pre-trade risk limits, kill switches, testing and monitoring obligations), and are supervised by the MNB.

Funds – eg, undertakings for collective investment in transferable securities (UCITS) or alternative investment funds (AIFs) – are regulated under the UCITS Directive or AIFMD, and typically do not require a separate MiFID licence themselves. Instead, the fund manager (management company or AIFM) is the regulated entity. If a fund engages in algorithmic or high-frequency strategies, the manager must ensure robust risk management, liquidity management and compliance systems, but the fund is not treated as a dealer unless it independently performs regulated investment services. If the manager executes trades directly as a dealer, MiFID obligations may apply alongside fund regulation.

In Hungary (under EU MiFID II rules), programmers themselves are not separately licensed or regulated simply because they write trading algorithms. Regulation attaches to the investment firm or credit institution that deploys the algorithm in live trading, not to the individual developer.

However, where a firm engages in algorithmic trading or HFT, MiFID II requires robust governance, testing, change of management and risk controls over algorithm design and deployment. This means programmers operate within a regulated framework: algorithms must be properly tested, subject to approval procedures, monitored in real time and capable of being switched off (“kill switch”). Firms must maintain detailed records of algorithm development and changes, and ensure staff involved are fit, properly supervised and trained. Internal controls typically include segregation of duties between development, testing and production environments.

If a programmer independently provides trading tools commercially (eg, selling algorithmic trading software to firms), they are generally not regulated as investment firms unless they also provide regulated services such as investment advice or order execution. That said, outsourcing rules, contractual oversight, ICT risk management (including under DORA), and potential liability exposure mean that programmers working for or supplying regulated firms are indirectly subject to regulatory expectations, even if they are not individually licensed.

The underwriting methodology itself is not prescribed in detail by regulation, but insurers must comply with the Hungarian Insurance Act and EU Solvency II framework.

In Hungary, different types of insurance are treated differently both in practice and under regulation. From a regulatory perspective, all insurers are governed by the Hungarian Insurance Act and the EU Solvency II framework, but capital requirements, technical provisions and risk management expectations differ depending on the nature and duration of the risk.

In industry practice, insurtech models also vary by line of business. Digital-first solutions are more common in motor, travel and simple casualty products. Life and investment-linked insurance products tend to involve more regulatory oversight, advice requirements and capital intensity, making them less frequently the focus of purely digital insurtech start-ups. Overall, while the core legal framework is unified, regulatory intensity and business models differ by insurance class.

In Hungary, regtech providers are not automatically regulated simply because they provide compliance technology. If they only supply software or technical services, they are generally treated as unregulated technology vendors. However, they may become regulated depending on their activities. If a regtech provider goes beyond providing tools and directly performs a regulated financial service, it may fall within the scope of financial services regulation.

Even where not directly regulated, regtech providers are often indirectly affected by regulation through outsourcing and ICT risk rules (including DORA), as regulated financial institutions must conduct due diligence, impose contractual controls (audit rights, data access, incident reporting) and monitor regtech vendors.

In Hungary, financial institutions typically require robust contractual protections from regtech and other technology providers to ensure performance, accuracy and regulatory compliance. Common terms include:

• detailed SLAs;
• warranties;
• audit and access rights (including rights for the MNB or other authorities where required);
• incident notification and breach reporting obligations;
• data protection and confidentiality clauses;
• business continuity and disaster recovery commitments;
• subcontracting restrictions;
• regulatory co-operation clauses;
• indemnities for compliance failures; and
• clear termination and exit/transition assistance provisions.

Many of these provisions are not purely market practice but are driven by regulation, particularly outsourcing and ICT risk requirements under sectoral rules.

In Hungary, traditional financial institutions are exploring blockchain primarily in back-office and infrastructure use cases rather than retail-facing crypto products. Banks and financial market participants are assessing distributed ledger technology (DLT) for settlement efficiency, tokenisation of securities, digital bonds, trade finance, cross-border payments and internal record-keeping.

Implementation is cautious and compliance-driven: institutions typically run pilot projects, consortium-based solutions or sandbox testing, ensuring alignment with regulation and operational resilience requirements. The focus is on efficiency, transparency and cost reduction, rather than replacing core regulated infrastructure.

While MNB in principle is open to blockchain and crypto innovation through its Innovation Hub and regulatory sandbox, and where on the crypto-asset front, Hungary claimed to be aligned with the EU’s MiCA regime, CASPs do not regard the scene as favourable. The EU Commission has initiated an infringement procedure against Hungary for imposing additional crypto-asset exchange validation requirements on CASPs.

In Hungary, not all blockchain assets are treated as regulated financial instruments; classification drives regulatory treatment and is informed by both MiFID II and MiCA, as implemented locally. Assets that meet the MiFID II definition of a financial instrument (eg, tokenised securities conveying rights like dividends or voting) remain subject to traditional securities and investment regulation, and are regulated on that basis rather than as “crypto-assets”. By contrast, most other digital assets that meet MiCA’s definition (eg, cryptocurrencies, utility tokens and stablecoins that are not e-money tokens) fall under the MiCA regime. Hungary’s implementation (via Act VII of 2024 on the Crypto-Assets Market) aligns with MiCA’s categories (electronic money tokens, asset-referenced tokens, “other” crypto-assets) and subjects them to different disclosure, governance and supervision rules, whereas traditional financial instruments continue to be regulated under the existing EU/Hungarian securities framework.

In Hungary, the regulation of blockchain asset “issuers” depends on the classification. If the token qualifies as a financial instrument (eg, a security token), the issuer must comply with MiFID II, the Prospectus Regulation and the MAR, including publication of an approved prospectus (unless an exemption applies). If the asset falls under MiCA, issuers of crypto-assets must publish a compliant crypto-asset white paper, while issuers of asset-referenced tokens or e-money tokens face stricter authorisation, governance and capital requirements.

In Hungary, blockchain asset trading platforms are regulated primarily under MiCA if they facilitate trading, exchange, custody or execution in crypto-assets that are not financial instruments; operators must be authorised as CASPs and comply with governance, conduct, capital, AML, market abuse and transparency requirements under MNB supervision. If the traded tokens qualify as financial instruments (eg, security tokens), the platform falls under MiFID II and must operate as a regulated market, MTF, OTF or licensed investment firm. Secondary trading through intermediaries is therefore regulated under MiCA or MiFID depending on the classification, while purely peer-to-peer trading without an identifiable service provider may fall outside direct licensing but still raises AML, sanctions and market abuse considerations.

In Hungary (under MiCA), the provision of crypto-asset staking services is regulated where it is offered as a service to clients by a centralised provider. If a platform pools or stakes clients’ crypto-assets on their behalf and distributes rewards, it will typically qualify as a CASP and require MiCA authorisation

Purely self-staking by individuals (where users stake directly on a protocol without an intermediary) is not itself regulated, but once a service provider intermediates, pools or manages staking for clients, MiCA conduct and custody rules apply.

In Hungary (under MiCA), crypto-asset lending provided as a service (eg, platforms lending out clients’ crypto or granting crypto-backed loans) is regulated where it qualifies as a crypto-asset service – typically involving custody and administration of crypto-assets or the operation of a trading/lending platform – and requires authorisation as a CASP, with conduct, governance, safeguarding, disclosure and AML obligations.

If the structure resembles traditional credit provision in fiat (eg, fiat loans secured by crypto collateral), domestic lending laws and consumer credit rules may also apply. Pure peer-to-peer arrangements without an identifiable intermediary may fall outside direct licensing, but most commercial crypto lending platforms operating professionally are regulated under MiCA and AML frameworks.

In Hungary, cryptocurrency derivatives are regulated as financial instruments under MiFID II, because derivatives qualify as financial instruments regardless of the nature of the underlying asset. Firms offering, brokering or executing crypto-derivatives must therefore be authorised as investment firms or credit institutions.

There is no standalone DeFi regulation in Hungary; instead, existing EU frameworks apply based on function and control. If a crypto-asset qualifies as a financial instrument, MiFID II applies; if it is an in-scope crypto-asset, MiCA applies to persons providing services “on a professional basis”.

A platform cannot avoid regulation simply by labelling itself “DeFi”. If there is an identifiable operator, developer, governance body or frontend provider facilitating trading, regulators may treat that party as a regulated service provider (eg, CASP or investment firm).

In Hungary, funds investing in blockchain assets are regulated based on their legal structure, not the asset alone. UCITS and AIFs are governed by the EU UCITS Directive or AIFMD and supervised by the MNB. The fund manager remains the regulated entity responsible for compliance.

The term “virtual currencies” is an older AML-driven concept referring mainly to cryptocurrencies used as a means of exchange (eg, Bitcoin) and focuses on AML/CFT obligations. By contrast, “crypto-assets” under MiCA is a broader regulatory category covering asset-referenced tokens, e-money tokens, and other tokens with specific issuer and service-provider rules.

In Hungary (under EU MiCA), NFTs are generally outside the regulatory perimeter if they are truly unique and non-fungible, as MiCA excludes genuinely unique tokens from its scope. However, if NFTs are issued in large series, are fractionalised or function economically like transferable financial instruments or crypto-assets, they may fall within MiCA or MiFID II.

In Hungary, stablecoins are regulated under the EU MiCA framework, where asset-referenced tokens and e-money tokens are subject to authorisation, governance and disclosure requirements, strict rules on reserve asset backing and (for e-money tokens) a right of redemption at par value, typically requiring issuance by a credit institution or authorised e-money institution.

In Hungary, open banking is primarily driven by PSD2, which has strongly supported its development by requiring banks to provide licensed third-party providers – account information service provider (AISPs) and payment initiation service provider (PISPs) – with secure access to payment accounts via APIs, subject to customer consent. The MNB supervises compliance, and banks must meet technical standards on strong customer authentication (SCA) and secure communication. While PSD2 created the legal foundation for fintech innovation and competition, practical implementation challenges have at times slowed adoption. Overall, regulation has enabled open banking structurally, but market uptake depends on technical readiness and business incentives rather than regulatory barriers alone.

Banks and technology providers address open banking privacy and security risks through SCA, secure APIs, encryption and strict consent management, in line with PSD2 and GDPR. They also implement enhanced vendor due diligence, data minimisation, monitoring and incident reporting frameworks to manage third-party and cybersecurity risks.

In Hungary, fraud in the financial services and fintech context is primarily governed by the Hungarian Criminal Code. In fintech specifically, fraud often overlaps with related offences such as information system fraud, misuse of payment instruments, money laundering and unauthorised access to IT systems. Regulatory consequences may also arise under AML, consumer protection and payment services laws, meaning firms can face both criminal liability (for individuals) and administrative sanctions.

There is focus on authorised push-payment (APP) fraud, phishing and social engineering scams, payment card fraud and account takeover attacks, especially in digital and instant payment environments.

In Hungary, a fintech service provider may be responsible for customer losses where it breaches contractual duties, fails to comply with statutory obligations, or is negligent in preventing fraud or unauthorised transactions. Under PSD2, providers are generally liable for unauthorised payment transactions unless the customer acted fraudulently or with gross negligence. Liability may also arise from defective services, data breaches or failure to meet disclosure and conduct standards, subject to contractual limits where permitted by law.