What an EMI Must Build Before It Can Scale
An EMI company is never just a legal entity with a licence and a payments idea. In practice, an electronic money institution is a regulated operating model that must show the regulator two things at the same time: first, that its IT environment is secure, resilient, and governable; second, that the people running it are competent, organised, and able to control the business on an ongoing basis. Under the EU framework, EMI authorisation follows the PSD2 authorisation logic as applied to electronic money institutions, and since 17 January 2025 DORA has brought harmonised ICT risk management requirements across the financial sector, including electronic money institutions.
This is exactly why “IT and personnel for EMI companies” is not a side topic. It is part of the licensing core. Regulators do not only ask whether the product works. They ask whether the institution can be run in a sound and prudent manner, whether incidents can be contained, whether critical systems are documented, whether outsourcing is controlled, and whether the management team actually has the time, competence, and structure to supervise the institution properly. The EBA’s authorisation framework for payment institutions and EMIs requires applicants to provide information on governance arrangements, internal control mechanisms, organisational structure, business continuity, outsourcing, and the identity and suitability of persons responsible for management.
Why IT matters so much for an EMI
For an EMI, IT is not just support infrastructure. It is the operational backbone of onboarding, transaction processing, wallet records, safeguarding logic, reconciliation, authentication, reporting, customer communication, and incident response. If the IT architecture is weak, the EMI does not simply become less efficient. It becomes harder to supervise, harder to audit, and more dangerous to run.
Since DORA applies from 17 January 2025, EMI companies are expected to maintain a proper ICT risk management framework, manage ICT-related incidents, control third-party technology risk, and test digital operational resilience in a structured way. The EBA also clarified in February 2025 that DORA now provides the harmonised ICT risk framework for entities including payment institutions and e-money institutions, while the older EBA ICT Guidelines were narrowed accordingly.
In practical terms, this means an EMI should not rely on vague statements like “our vendor handles security.” The institution itself remains responsible for understanding its systems, risks, dependencies, and controls. That includes user access governance, segregation of duties, logging, backup logic, recovery procedures, change management, vulnerability handling, and visibility over outsourced or cloud-based components. DORA’s model is not built around blind delegation. It is built around accountable oversight.
What IT stack regulators expect to see
A regulator usually does not require one specific software brand. What matters is whether the EMI can explain its operating architecture clearly and show that the setup is fit for the licensed activity.
In most cases, the minimum credible EMI technology environment includes:
Core transaction and ledger logic
The EMI must be able to explain how balances are created, updated, restricted, and reconciled. If the institution issues electronic money, the ledger logic cannot be treated as a black box. The regulator will want confidence that records are complete, traceable, and controlled.
Security and access controls
Access to production systems, customer data, payment functionality, and administrative rights should be restricted and documented. Shared admin accounts, informal credentials, or unmanaged privileged access are the kind of weaknesses that quickly destroy confidence in the control environment.
Audit trails and logging
EMIs should be able to reconstruct who did what, when, and in which system. This matters for fraud review, operational incidents, dispute handling, internal investigations, and supervisory inspections.
Incident management and business continuity
A serious EMI needs incident escalation paths, fallback logic, backups, recovery planning, and clear internal responsibilities. Under DORA, ICT incident management and operational resilience are not optional nice-to-haves. They sit inside the regulatory framework itself.
5. Outsourcing and third-party oversight
Many EMI companies use external providers for core banking technology, cloud hosting, KYC tools, fraud engines, card processing, or customer support systems. That does not reduce the EMI’s responsibility. It increases the need for vendor due diligence, contractual clarity, monitoring, exit planning, and concentration-risk awareness. DORA explicitly addresses ICT third-party risk management for financial entities.
Personnel for EMI companies: who actually needs to be in place
A common founder mistake is to think that staffing can be fixed after authorisation. In reality, regulators assess whether the EMI has enough people, enough competence, and enough management capacity before the institution is allowed to scale.
The EBA authorisation framework requires information on the persons responsible for the management of the institution, their suitability, and the organisational arrangements supporting the business. Competent authorities may refuse authorisation where the governance or management setup does not support sound and prudent management.
A workable EMI staffing model usually includes the following roles, whether fully internal or partly outsourced with proper oversight:
Management body / executive leadership
Someone must own the business model, regulatory strategy, and day-to-day running of the institution. This is not a nominal founder function. Regulators look at competence, availability, and real decision-making capacity.
Compliance function
An EMI needs a compliance capability that can monitor obligations, maintain policies, track regulatory changes, and support internal controls. In small institutions this may be lean, but it still needs authority, access, and continuity.
AML / financial crime function
Given the ML/TF exposure in payments and e-money, the EMI must be able to manage onboarding controls, transaction monitoring, sanctions screening, escalation, and suspicious activity reporting under applicable local law.
Risk management
Even if the institution is small, someone must identify and monitor operational, compliance, outsourcing, fraud, ICT, and liquidity-related risks. A licence does not remove the need for risk ownership. It increases it.
IT / security ownership
Not every EMI needs a huge internal engineering team on day one. But every EMI needs accountable ICT ownership. If technology is outsourced, internal oversight becomes even more important, not less.
Operations and customer support
Payments businesses generate exceptions: failed transactions, customer complaints, account restrictions, reconciliation breaks, disputes, and onboarding edge cases. Without an operations layer, the EMI becomes fragile very quickly.
The real question is not headcount — it is controllability
Regulators do not only ask, “How many employees do you have?” They ask whether the institution is controllable. A lean EMI with a well-defined governance model, clear outsourcing boundaries, strong documentation, and competent function owners may look more credible than a larger company with blurry responsibilities and scattered systems.
That is why good EMI staffing is less about building a huge team and more about building a defensible structure:
- clear reporting lines,
- defined control functions,
- documented escalation paths,
- decision rights for key issues,
- coverage for absences and incidents,
- no dangerous concentration of knowledge in one founder or one vendor.
This is especially important in EMI businesses where growth can outpace governance. A company may onboard users quickly, add countries, add payment flows, add cards, add partners — and suddenly realise that the internal team can no longer explain how the institution is being controlled.
Outsourcing does not solve weak personnel planning
Many EMI founders assume that outsourced compliance, outsourced AML, outsourced IT, and outsourced support together create a compliant institution. They do not. Outsourcing can be a valid operating model, but only if the EMI itself remains able to govern the outsourced setup.
The authorisation framework and the broader prudential logic for EMIs do not allow responsibility to disappear into vendor contracts. The institution must still understand the services, monitor the provider, manage risk, and take action when something breaks. An outsourced model without internal ownership usually looks efficient in a pitch deck and weak in front of a regulator.
Typical weaknesses in EMI IT and staffing models
The same problems appear again and again:
- Founder-centric governance.
One person approves everything, understands everything, and controls everything. That may work for a startup sprint, but it does not look like resilient governance. - Unclear ICT ownership.
The company uses multiple vendors, but nobody internally can map the full architecture, access rights, integrations, or failure points. - Thin compliance layer.
Policies exist, but nobody updates them, monitors them, or checks whether operations still match what was described in the authorisation file. - No real incident readiness.
There is a security policy, but no tested escalation process, no decision tree, and no practical recovery choreography. - Outsourcing without control.
Critical services are delegated, but oversight is limited to invoice approval and the occasional vendor call.
What a regulator-friendly EMI setup looks like
A credible EMI does not need to be enormous, but it should be coherent. The IT side should be documented, access-controlled, resilient, and supervised. The personnel side should show real competence, real accountability, and enough capacity for the institution’s current and planned scale.
That usually means:
- an explainable system architecture,
- named ICT ownership,
- incident and continuity procedures,
- proper outsourcing records and governance,
- management with time and competence to supervise,
- functioning compliance / AML / risk coverage,
- staffing proportional to the business model, transaction profile, and growth plan.
Conclusion
IT and personnel for EMI companies are not “post-licensing details.” They are part of what makes an EMI licensable and sustainable in the first place. In 2026, the institutions that look strongest are usually not the ones with the loudest product story. They are the ones that can show the regulator a controlled operating model: secure systems, resilient architecture, accountable people, and governance that still works when the business grows.
An EMI can outsource many tasks. It cannot outsource responsibility. And that is the main principle behind both the IT and personnel expectations in the EU regulatory framework.
Start a Real EMI
We help you structure, document, and defend your capital so it meets ČNB expectations — not just the legal minimum.
Book EMI Strategy CallFAQ: IT and Personnel for EMI Companies
Do EMI companies need a full internal IT department?
Not necessarily. An EMI may outsource parts of its technology stack, but it still needs internal ICT ownership and oversight. Under DORA, financial entities remain responsible for managing ICT risk, incidents, testing, and third-party technology risk.
Does DORA apply to EMI companies?
Yes. DORA applies from 17 January 2025 and covers financial entities including electronic money institutions. The EBA confirmed in 2025 that DORA now provides the harmonised ICT risk management framework for those entities.
What personnel do regulators usually expect an EMI to have?
At minimum, regulators expect a credible management body and appropriate governance arrangements, along with sufficient capacity for compliance, risk, AML/financial crime, operations, and ICT oversight in proportion to the business model.
Can compliance and AML be outsourced in an EMI?
Some functions can be outsourced depending on the jurisdiction and model, but the EMI itself remains responsible for control, oversight, and regulatory compliance. Outsourcing reduces internal execution load, not accountability.
What is the difference between an EMI and a PI?
A Payment Institution provides payment services, while an EMI may also issue electronic money and maintain customer balances in that form. This distinction has a major impact on the business model and on the applicable regulatory framework.
What is the biggest mistake in EMI staffing?
A very common mistake is treating key functions as formal titles without real capacity, authority, or reporting lines. Regulators focus on whether the institution can be managed in a sound and prudent way, not whether the org chart looks impressive.
