The EMI Question.
When a Payment Institution Is Not a Bank,
and Why It Matters

by Vladimir Shuvalov

Return to the Insights page →

The question arrives in almost every engagement that involves an international structure and a banking difficulty. The client has been reading, or has been advised, or has simply noticed that there are institutions offering business accounts that do not appear to have the same entry barriers as banks. The onboarding is faster. The documentation requirements are lighter. The compliance questions are fewer and less searching. The account can be opened in days rather than months.

The question is: why not use one of these instead?

It is a reasonable question. And the answer — which is not "no", but is considerably more nuanced than "yes" — is one that most clients have not had explained to them clearly. The financial services industry does not, on the whole, have a strong incentive to explain the differences between its own products. Advisers who recommend EMIs sometimes have commercial relationships with them. Advisers who recommend against them sometimes work primarily with banks. Neither perspective is necessarily wrong. Neither is complete.

What follows is the architectural answer — not a licensing comparison, not a regulatory summary, but an account of what changes when a payment institution replaces or supplements a bank in an international structure, and what those changes mean in practice.

What an EMI Actually Is

An Electronic Money Institution is a regulated entity authorised to issue electronic money and provide payment services. It is subject to capital requirements, safeguarding obligations, and AML/CFT compliance requirements that are, in formal terms, comparable to those applied to banks.

The key distinction — and it is the distinction that matters most for structural purposes — is that an EMI is not a bank. It cannot lend. It cannot hold deposits in the banking sense. The funds it holds on behalf of clients are not covered by deposit guarantee schemes. And its position in the correspondent banking system is different from a bank's position: most EMIs access payment infrastructure through a bank, not directly.

This is not a criticism of EMIs. It is a description of what they are. The question of whether an EMI is appropriate for a given situation is an architectural question, not a quality judgment.

What Changes Structurally

When a business account moves from a bank to an EMI — or when an EMI account is added alongside a bank account — several things change simultaneously, and not all of them are immediately visible.

The nature of the relationship changes. A bank account is a deposit relationship. The bank owes the account holder a debt. The regulatory protections around that relationship — deposit insurance, the framework for insolvency, the conduct rules that govern how the account can be restricted or closed — are those that apply to banks. An EMI account is a payment services relationship. The legal framework is different. The protections are different. In practice, for routine transactions, this distinction is invisible. Under stress — in the event of the EMI's insolvency, in the event of an account restriction, in the event of a dispute about a frozen payment — it matters considerably.

The correspondent banking question. Most EMIs access the payment system through one or more partner banks. This means that a payment made from an EMI account passes through a bank at some point in the chain — and that bank applies its own compliance judgements to what it sees. An EMI that has adequate AML systems may still find that a client's transaction is questioned or delayed by the correspondent bank through which the payment routes. The client's view is that they have a compliant EMI account. The correspondent bank's view is that it is seeing a payment from an institution it has a relationship with, carrying client funds whose origin it is evaluating. These are not the same view, and the difference produces friction that the client did not anticipate and the EMI cannot fully control.

The due diligence signal. This is the structural consequence that matters most, and the one most rarely discussed. When an investor, an acquirer, or a sophisticated counterparty conducts due diligence on a business, they look at the banking relationships. A business that banks exclusively with one or more EMIs — that has no relationship with a licensed deposit-taking institution — is, from the perspective of most due diligence processes, a business that could not establish or maintain a conventional banking relationship. That inference may be incorrect. The business may have chosen EMIs for operational reasons that are entirely legitimate. But the inference will be drawn, it will require explanation, and the explanation will need to be more compelling than the original question.

This is not a reason to avoid EMIs. It is a reason to understand what their presence in a structure communicates, and to manage that communication deliberately.

When the Problem Becomes Visible

Most businesses that have built their financial architecture around EMIs do not discover the consequences until a specific moment — and that moment is almost always external, not self-generated.

The most common version is the due diligence process before a transaction. An investor or acquirer requests a list of banking relationships. The business provides EMI account details. The question that follows — "do you have a relationship with a licensed bank?" — is not hostile. It is a standard check. But it immediately reframes the conversation: the business now needs to explain why it relies on payment institutions rather than banks, in a context where the other party is already forming a view about structural risk. What should have been a routine disclosure becomes a negotiation about risk adjustment.

The second version is the bank's own compliance review. A business maintains a bank account alongside one or more EMI accounts. The bank, during a periodic KYC refresh, reviews the account activity and sees significant flows moving to and from payment institutions. The question arrives: what are these accounts, and why does the business use them? If the answer has not been prepared — if there is no clear documentary account of why each EMI account exists and what function it serves — the conversation becomes longer and more difficult than it needed to be. In some cases, it triggers a broader review of the banking relationship.

Neither of these moments is catastrophic if the architecture has been designed deliberately and documented clearly. Both are considerably harder to manage if they are the first time the business has been asked to explain itself.

Where EMIs Work Well

The architecture that works is not one that avoids EMIs or one that relies on them exclusively. It is one that uses them for what they are genuinely suited for and maintains conventional banking relationships for what those relationships are designed to do.

EMIs are genuinely well suited to several things that banks handle poorly.

Multi-currency operational accounts. A business with revenues in several currencies, operating across multiple jurisdictions, often needs to move money quickly and cheaply between accounts denominated in different currencies. EMIs — particularly the larger, more established ones — have built infrastructure specifically for this purpose. The cost and speed advantages over traditional bank transfers are real and significant for businesses with frequent international payment flows.

Faster onboarding for new business lines or entities. When a new entity is established within a group and needs an operational account quickly, an EMI can often provide one in days. This is not a replacement for the banking relationship that the entity will eventually need. It is a solution for the period between establishment and banking, which can otherwise be an operational gap of several months.

Payment processing for specific transaction types. Businesses that process high volumes of small transactions — e-commerce, marketplace models, subscription businesses — often find that EMIs offer better infrastructure for their specific transaction patterns than the bank accounts designed for conventional corporate activity.

Jurisdictions where banking access is genuinely difficult. For businesses operating in markets where conventional banking relationships are hard to establish, EMIs can provide a functional payment infrastructure that enables the business to operate while the banking architecture is developed.

In each of these cases, the EMI serves a defined function within a larger architecture. It is not the architecture itself.

The Mistakes That Create Problems

The structural problems that arise from EMI usage fall into three consistent patterns.

Replacing banking with EMI accounts because banking was difficult. The business encountered banking friction — account closures, onboarding failures, compliance questions it could not answer satisfactorily — and resolved the immediate operational problem by moving to EMIs. The banking problem remains. The structure still produces the same signals to banks. The EMI account functions for daily operations, but the underlying condition that made banking difficult has not been addressed. When the due diligence moment arrives, or when the EMI itself conducts a compliance review, the situation is exactly where it was — except that time has passed and the structural problem has not been examined.

Adding EMI accounts without considering what they add to the compliance picture. A business with a conventional banking relationship adds an EMI account for operational convenience — faster transfers, better multi-currency functionality. This is legitimate. But the bank now sees transactions flowing to and from a payment institution, and the compliance picture changes. If the bank does not understand why the EMI account is part of the structure, or if the explanation has not been provided proactively, the transactions become a source of questions. What should have been an operational convenience becomes a compliance conversation.

Treating EMI accounts as equivalent to bank accounts for all purposes. In many jurisdictions, contracts, financing arrangements, and regulatory submissions require a "bank account" in a specific sense — a deposit account held at a licensed deposit-taking institution. An EMI account does not satisfy this requirement. A business that has relied on EMI accounts for all financial activity may find, at a critical moment — a financing round, a regulatory application, a contract with a large counterparty — that it does not have the bank account the situation requires, and that establishing one takes longer than the situation allows.

The Architectural Answer

The right question is not whether to use EMIs. It is what function each element of the financial architecture serves, and whether the architecture as a whole communicates what it needs to communicate to the parties who will examine it.

A well-constructed financial architecture for an international business typically rests on three elements: conventional banking relationships with licensed deposit-taking institutions, held by the principal operating entities and the holding structure; EMI accounts used for specific operational purposes — multi-currency management, high-volume payment processing, jurisdictions where bank access is limited; and a clear documentary explanation of why each element is present and what function it serves.

That documentation is not optional. It is the difference between a financial architecture that can be explained to a bank, an investor, or a regulator in ten minutes, and one that generates questions every time it is examined.

The EMI question, like most architectural questions, does not have a universal answer. It has a situational one. The situation that needs to be examined is not which institution offers better terms. It is what the structure, as a whole, communicates — and whether that communication serves the business or complicates it.

Vladimir Shuvalov works with international businesses and private clients on corporate structure, banking acceptability, and cryptocurrency architecture from Nicosia, Cyprus.
Thinking Globally — thinking-globally.com

Return to the Insights page →

Thinking Globally Consulting Limited
Registered in England & Wales · Company No. 17138834
128 City Road, London EC1V 2NX, United Kingdom

© 2026 Thinking Globally Consulting Limited · All rights reserved