BSP EMI License Explained: What It Means for Payment Providers in the Philippines

Why "BSP EMI License" Keeps Showing Up in My Due-Diligence Folder

I run payments infrastructure for a company that ships product into the Philippines from a base in China, and every time we add a new local collection or payout partner, the same two acronyms show up in the contract review: EMI and OPS. Both sit under the Bangko Sentral ng Pilipinas, the Philippines' central bank, and both get waved around by sales teams as proof of being "licensed." They are not the same license, they do not authorize the same activities, and conflating them is exactly how a merchant ends up routing money through an entity that is registered for one thing while quietly doing another.

This isn't a general explainer of what an EMI is. It's the checklist I wish I'd had the first time our finance team asked, point blank, "if this provider disappears tomorrow, what happens to our settlement funds, and can you prove they were ever allowed to hold them in the first place." If you're evaluating a payment gateway, aggregator, or wallet-adjacent provider in the Philippines and need to translate "BSP-licensed" into something your CFO can sign off on, this is written for you.

What BSP Actually Oversees

BSP is the Philippines' central bank, established under the New Central Bank Act. Historically its licensing regimes were built around banks and quasi-banks. The rise of mobile wallets and third-party payment processors forced BSP to build newer, narrower license categories that regulate specific functions rather than entire institutions. Two of those categories now matter enormously to anyone moving commercial money through the Philippines: the Electronic Money Issuer (EMI) license and the Operator of Payment System (OPS) registration under the National Payment Systems Act (Republic Act No. 11127, signed in 2018).

The distinction is not academic. A company can legally hold one without the other, and the activities each license covers are different enough that a provider holding only one of the two may simply be unable to perform the role your contract describes. When a sales deck says "BSP-regulated," ask which of the two — or whether it's both — before you ask about pricing.

What an EMI License Authorizes

An Electronic Money Issuer license lets a company issue electronic money: it can accept funds from a customer and convert that cash into a stored value balance the customer can later spend, transfer, or cash out. The e-money framework BSP built for this, dating back to a circular first issued in 2009 and expanded repeatedly since, treats e-money as a liability the issuer owes the holder — similar in spirit to how a bank treats a deposit, though an EMI is not a bank and cannot lend out that balance the way a bank lends deposits.

Practically, holding an EMI license is what lets a provider operate something that behaves like a wallet: a running balance tied to an account, which a merchant or consumer can top up, hold, and draw down later. It also comes bundled with specific obligations — safeguarding of the money backing outstanding e-money balances, capital requirements scaled to the volume issued, and reporting duties to BSP. For a merchant, the relevant question isn't "do they have an EMI license" in the abstract — it's "does the service I'm actually buying from them require one," because not every payment flow does.

This is also where AMLA KYC obligations that come bundled with these licenses start to matter for your own onboarding paperwork. If your provider is issuing e-money to end users, BSP expects identity verification on those end users, not just on your merchant account — and that obligation flows downstream into how much documentation your own customers will be asked for.

What an OPS License Authorizes

An Operator of Payment System registration is a different animal. It covers entities that operate a payment system — the rails, clearing arrangements, or switching infrastructure that let money move between participants — without necessarily issuing e-money themselves. Under the National Payment Systems Act, BSP oversees payment systems as critical financial infrastructure, and operators of those systems register with BSP so the central bank has visibility into who is moving what, at what scale, between which counterparties.

In the commercial payments context a foreign merchant actually encounters, an OPS registration is typically what covers the technical operation of collection and disbursement rails: a company that routes your customer's GCash payment, switches a QRPH transaction, or processes a batch payout to multiple bank accounts on your behalf, without itself being the party holding a stored-value balance for your customers. An OPS-only entity is not, by itself, authorized to issue e-money or hold customer balances as a liability the way an EMI does.

The practical upshot: a company that only moves money on behalf of others, and never holds a stored balance in its own name, is in OPS territory. A company that lets your customers keep a running balance is in EMI territory. Plenty of providers legitimately need both licenses because they do both things — which is exactly the scenario worth asking about directly.

EMI vs OPS: A Side-by-Side Comparison

I built this table for our own internal vendor file after getting tired of re-explaining the distinction to colleagues on every renewal cycle. Treat it as a starting point for your own due diligence, not a legal opinion.

Dimension	EMI (Electronic Money Issuer)	OPS (Operator of Payment System)
Legal basis	BSP's e-money issuance framework	National Payment Systems Act (RA 11127)
Core authorization	Issue electronic money; hold customer value as a liability	Operate, switch, or clear payment transactions between participants
Can it hold a customer's stored balance?	Yes — that's the defining activity	Not inherently; it moves funds rather than holding them as its own liability
Typical merchant-facing role	Wallet-style accounts, top-up and cash-out services	Collection/disbursement rails, switching, aggregation infrastructure
Key downstream obligation	Safeguarding of funds backing e-money liabilities, AMLA/KYC on e-money holders	Operational and reporting standards for the payment system itself
Can one entity hold both?	Yes, and many serious payment companies in the Philippines do	Yes — see above

A single sentence worth remembering: an EMI license is about what a company is allowed to hold; an OPS registration is about what a company is allowed to move. A merchant who only checks one side of that sentence has only checked half the risk.

Why a Provider Holding Both Licenses Changes My Risk Calculus

Here's the scenario that actually worries a CFO signing off on a new payment partner: your provider collects from end customers, holds the funds briefly before remitting to your settlement account, and also disburses payouts on your behalf to employees, affiliates, or suppliers. That combination — holding funds briefly and also moving money out on your instructions — can touch both license categories depending on exactly how the funds sit in between. If a provider holds a balance, even temporarily, without an EMI license, or operates payment rails at scale without an OPS registration, the exposure isn't limited to the provider. The activity itself can get challenged by the regulator, settlement funds can get frozen as part of an enforcement action, and your own company can get pulled into questions about why it routed commercial volume through an unregistered entity.

This is the specific reason SMARTPAY's dual BSP OPS and EMI licensing matters in a due-diligence conversation rather than as a marketing line. Holding both means the entity operating your collection and disbursement rails and the entity potentially touching e-money balances along the way are the same regulated legal person, under the same regulator, subject to the same reporting obligations — not a licensed shell with unlicensed subcontractors doing the actual money movement underneath it. For a foreign merchant who cannot easily inspect a Philippine corporate structure from abroad, that single fact collapses a lot of the structural risk you'd otherwise have to diligence layer by layer.

A Due-Diligence Checklist Before You Sign

I keep a working version of this table next to every vendor contract we review. It is deliberately short enough to actually get used in a real procurement cycle.

What to ask	Why it matters	Answer that should concern you
Which BSP license(s) do you hold — EMI, OPS, both?	Tells you whether they're authorized for holding balances, moving money, or neither	"We're BSP-compliant" without naming a specific license category
Does your service involve holding a balance on my customers' behalf?	Determines whether an EMI license is actually required for what you're buying	Vague answers about where funds sit "in transit"
Who is the legal entity named on the license — is it the entity I'm contracting with?	A licensed parent company doesn't make an unlicensed subsidiary compliant	The contracting entity differs from the licensed entity with no explanation
Can you point me to where I can verify this independently?	A real license is checkable; a claim is not	Reluctance to provide a license number or registration reference
What AMLA/KYC data will you require from my end customers?	Licensed entities have real reporting obligations that shape onboarding flows	"We don't need any of that" for anything resembling a wallet or stored balance

For the technical side of verification, I'd point you toward a five-step due-diligence checklist for verifying a provider's BSP status and a complementary registry-based way to verify a BSP license directly against the central bank's own published list rather than taking a logo on a website at face value. Both take under ten minutes and should be standard practice before any contract is signed, not after.

On the technical integration side, one signal I look for during a sandbox trial is whether the provider's API actually enforces the identity fields their license obligates them to collect. A provider that is serious about its AMLA/KYC obligations builds that enforcement into the request schema itself, not just into a manual review queue. Here's a simplified version of the kind of request-signing logic I'd expect to see required, not optional, from a properly licensed collection API:

const crypto = require('crypto');

// Build a signed transaction record the API will actually accept.
// A licensed EMI/OPS enforces payer identity fields on top of the
// usual order fields -- an unlicensed aggregator usually skips this.
function buildSignedRequest(payload, apiSecret) {
  const record = {
    merchant_id: payload.merchantId,
    order_no: payload.orderNo,
    amount: payload.amount,       // numeric string, no currency symbol
    currency: 'PHP',
    payer_name: payload.payerName,
    payer_id_type: payload.payerIdType, // e.g. 'passport', 'national_id'
    timestamp: Date.now(),
  };

  const raw = Object.keys(record)
    .sort()
    .map((key) => `${key}=${record[key]}`)
    .join('&');

  const sign = crypto.createHmac('sha256', apiSecret).update(raw).digest('hex');

  return { ...record, sign };
}

const request = buildSignedRequest({
  merchantId: 'MERCH-00123',
  orderNo: 'ORDER-20261003-001',
  amount: orderAmount,           // supplied by your own order system
  payerName: 'Juan Dela Cruz',
  payerIdType: 'national_id',
}, process.env.SMARTPAY_API_SECRET);

// A compliant endpoint will reject this request if payer_id_type
// is missing once the transaction crosses the provider's own
// internal AMLA threshold -- that rejection is a feature, not a bug.

If a sandbox environment accepts transactions with none of that identity scaffolding regardless of size, that's a tell worth raising internally before you scale volume through it. For a broader walkthrough of how collection and disbursement are actually wired together on a compliant stack, see a developer's guide to payment collection and disbursement in the Philippines.

Frequently Asked Questions

Is an EMI license the same thing as being "licensed by BSP"?

No. "Licensed by BSP" is a category, not a specific authorization. A company can be BSP-regulated under several different frameworks — EMI, OPS, a bank or quasi-bank license, a money service business registration — and each one authorizes different activities. Ask which specific license applies to the service you're buying.

Can a company operate legally with only an OPS registration and no EMI license?

Yes, if the activity it performs is limited to operating payment rails — switching, clearing, routing transactions — without itself holding customer balances as a liability. Plenty of legitimate infrastructure providers in the Philippines payment space fall into exactly this category and have no need for an EMI license.

How do I verify a provider's BSP license status myself, without taking their word for it?

BSP maintains public lists of its regulated and registered entities by category. Cross-check the exact legal entity name on your contract — not just the brand name on the website — against that list. If the names don't match, or the entity isn't listed under the category they're claiming, that's a conversation to have before signing, not after.

What actually happens if I route payments through an unlicensed provider?

Beyond the provider's own regulatory exposure, you risk disrupted settlement if BSP or another agency takes enforcement action, difficulty recovering funds held by an unregistered entity, and your own company being pulled into scrutiny over why commercial volume moved through it. None of that is a hypothetical in a market where BSP has actively tightened oversight of payment channels in recent years.

Does a BSP license mean my settlement funds are insured the way a bank deposit might be?

No. An EMI license comes with fund safeguarding requirements for the money backing outstanding e-money balances, which is a meaningfully different protection than deposit insurance on a bank account. Don't assume license equals insurance — ask the provider directly how the funds backing your balance are segregated and safeguarded.

Why do some providers say "BSP-registered" instead of "BSP-licensed"?

The wording sometimes reflects a real distinction — registration and licensing are not always interchangeable across BSP's different frameworks — but it's also a phrase vague enough to deserve a direct follow-up question. Ask for the specific license or registration category and the reference you can look up yourself.

Is there anything I should ask for beyond the license itself?

Yes. Ask whether the entity named on the license is the same entity on your contract, how customer funds are segregated operationally (not just on paper), and what KYC data flows will be required from your own end customers as a result of the provider's obligations. A license tells you the provider is in scope for regulation; it doesn't tell you how well they operate inside that scope.

None of this is about collecting acronyms. It's about answering, in plain language, why your company is comfortable routing commercial funds through a specific entity in a specific jurisdiction. "They mentioned BSP in their deck" is not due diligence. Knowing which license covers which activity, confirming the contracting entity actually holds it, and understanding the obligations bundled with it — that's due diligence you can defend to your own board.

SMARTPAY holds both BSP OPS and EMI licensing, which is why we're comfortable walking merchants through this comparison rather than asking them to take a badge on a website at face value. If you're mid-way through evaluating a payment partner in the Philippines and want a second set of eyes on a contract, a license reference, or how a specific flow should be structured, reach out on Telegram at @LouisSMARTPAY or by email at [email protected].