License for Money Transfer Business in India: Which Route Fits?
India has no single license covering every money transfer activity. The right regulatory route depends on whose funds you handle, the payment purpose, and whether you aggregate payments, exchange currency, or issue stored value.
There is no universal license for a money transfer business in India. The required Reserve Bank of India (RBI) authorization depends on your activity: payment aggregation, cross-border merchant collections, foreign exchange, personal inward remittances, or regulated wallet issuance. A company paying its own suppliers through authorized providers is different from a business accepting and transferring money for customers.
For finance teams managing international payouts, the first question is therefore not “Which license should we buy?” It is “Which regulated activity does our funds flow create?” Transaction volume alone does not answer that question.
This guide focuses on Indian operations and India-linked commercial payment flows. It is a planning framework, not a legal determination; confirm current RBI directions and your proposed structure with Indian regulatory counsel before launching.
Start with the activity, not the payment rail
The Payment and Settlement Systems Act, 2007 governs authorization to operate payment systems. The Foreign Exchange Management Act, 1999 (FEMA) governs foreign exchange activities. A cross-border product can engage both frameworks.
Before selecting a route, document:
- Whose obligation is being paid: your company's invoice, a customer's remittance, or a marketplace seller's proceeds?
- Who controls the funds: which legal entity receives, holds, converts, releases, and refunds them?
- Payment purpose: goods, services, family maintenance, or another permitted purpose?
- Direction: domestic, inbound to India, or outbound from India?
- Customer relationship: who contracts with and onboards the payer and recipient?
Using NEFT, a bank API, or an overseas collection account does not itself establish permission to conduct the underlying business. An INR payment into an Indian bank account can still be the final leg of a cross-border commercial transaction.
Which regulatory route fits your business?
These categories are not interchangeable licenses. More than one regulated participant may be needed to execute a payment.
| Proposed activity | Route to assess | Operational limitation |
|---|---|---|
| Collect and settle domestic merchant payments | Payment aggregator authorization | Does not automatically cover cross-border aggregation |
| Aggregate eligible import or export payments | Cross-border payment aggregator authorization | Scope must match the payment direction and activity |
| Conduct foreign exchange or remittance activities | Relevant FEMA authorized-person category | Permission is limited to the authorized scope |
| Distribute eligible personal inward remittances | Money Transfer Service Scheme arrangement | Not a commercial supplier-payment route |
| Issue regulated stored-value wallets or prepaid instruments | Prepaid payment instrument authorization | Wallet permission is not general remittance permission |
| Pay your own company's vendors | Authorized bank or payment-provider relationship | Underlying purpose and documentation still matter |
Payment aggregator authorization: merchant money, not every transfer
A payment aggregator facilitates merchant payments and handles funds within the applicable collection and settlement structure. The RBI's September 2025 framework distinguishes online, physical, and cross-border aggregation, as described in Saraf and Partners' analysis of the Payment Aggregator Directions.
For a non-bank applicant, the framework requires an Indian-incorporated company. The cited analysis describes minimum net worth of INR 15 crore at application, increasing to INR 25 crore by the end of the third financial year after authorization. These are net-worth requirements, not a license purchase price or a complete launch budget.
Cross-border payment aggregation requires separate attention. Import, export, and combined scopes are distinguished in Skydo's explanation of PA-CB authorization. Domestic authorization alone should not be treated as permission to aggregate cross-border payments.
For operators, this means mapping each collection and settlement account to its permitted function. Do not assume that one pooled balance can support domestic merchant settlements, export receipts, outward supplier payments, and refunds without restrictions.
Foreign exchange authorization: the permitted activity matters
FEMA authorization is separate from payment-system authorization. Authorized Dealer Category-I banks, Category-II entities, and Full-Fledged Money Changers have different permitted activities. An FFMC license is not a general license to transfer business payments internationally.
Ask which entity performs the foreign exchange transaction and under which permission. A service provider arranging a conversion is not necessarily authorized to deal in foreign exchange itself.
The supplied research includes a press report of expanded AD-II permissions in May 2026, but does not independently establish the governing RBI text. Do not build a trade-remittance product around that report: obtain the applicable direction and the provider's authorization conditions.
MTSS: personal inward remittances, not vendor invoices
The Money Transfer Service Scheme supports eligible personal remittances from abroad, including family maintenance and assistance to visiting tourists. It is not a substitute for commercial import or export payment infrastructure. Razorpay's inward-remittance guide explains the distinction between personal-remittance channels and business receipts.
A contractor's service invoice does not become a family remittance because the beneficiary is an individual. The economic purpose, not simply the recipient's legal form, determines the appropriate route.
PPI authorization: stored value is a separate question
Issuing regulated prepaid payment instruments can trigger a separate authorization requirement. The RBI's November 2022 PPI FAQs explain instrument categories and distinguish closed-system instruments from RBI-regulated PPIs.
That historical guidance should not be treated as confirmation of every current permission. The supplied research identifies draft PPI changes circulated in 2026, but does not establish their finalization. Verify the operative rules before relying on capital thresholds, transfer functionality, or cross-border use.
Do you need your own authorization or a regulated partner?
Paying your company's own obligations does not, by itself, make the company a money transfer operator. However, receiving customer funds, maintaining customer balances, or deciding how third-party proceeds are distributed can change the analysis.
A partner-led model can reduce the regulated activities you perform directly, but it is not a blanket exemption. Contracts and actual operations must agree on who handles funds, onboards customers, conducts checks, executes transfers, and resolves complaints.
Before integration, request the partner's exact legal name, authorization status, permitted activities, relevant restrictions, and banking arrangements. Distinguish an application or in-principle approval from permission to conduct the proposed live activity. Our guide to evaluating cross-border payment companies in India addresses the subsequent provider-selection decision.
Build an application and launch-readiness checklist
The filing route and documents depend on the authorization category. Prepare the following before treating an application as submission-ready:
- Written regulatory classification. Describe each service, payment purpose, jurisdiction, funds owner, and regulated participant. Include refunds and failed transfers.
- Corporate and ownership records. Prepare incorporation documents, appropriate constitutional objects, ownership information, and director and management disclosures.
- Capital evidence. Obtain the required auditor certification and model ongoing compliance. Separate regulatory net worth from operating expenditure and settlement liquidity.
- Banking and account design. Document account ownership, permitted credits and debits, safeguarding arrangements, reconciliation, and settlement responsibilities.
- Compliance procedures. Define customer due diligence, beneficial-owner checks, sanctions screening, transaction monitoring, reporting, and escalation responsibilities.
- Technology controls. Document access rights, security policies, audit trails, business continuity, incident response, and applicable data-storage requirements.
- Submission and launch gates. Confirm the current RBI application channel, required attachments, approval conditions, and any restrictions before commencing business.
Supporting KYC/KYB and tax-documentation workflows can organize evidence, but software does not confer regulatory permission or replace the accountable entity's obligations.
Turn the legal analysis into a payment-level control
The most useful output is not just a license checklist. It is an eligibility record attached to each payment, showing why that transaction belongs on the selected route.
Capture the payer and beneficiary legal identities, residency, commercial purpose, invoice or contract reference, currency, destination account, and responsible regulated provider. For Indian bank payouts, beneficiary name, account number, and IFSC will commonly be needed; cross-border documentation depends on the purpose and provider. Confirm requirements before promising a payment date.
Hypothetical example: An overseas company pays Indian designers for services. Its operations team should classify the payments as commercial receipts, not personal remittances. It should establish who onboards the designers, which permitted route carries the funds, who performs FX, and what receipt evidence the designers can obtain.
If that company later collects buyers' money and distributes proceeds to independent sellers, the original analysis may no longer hold. Customer-fund handling and merchant settlement introduce different questions, even if the payout API remains unchanged.
Maintain a launch gate for each new payment purpose, direction, or customer type. Separately measure FX costs, fees, document-review delays, and final credit confirmation: regulatory eligibility and payment speed are different controls.
Choose the permission before scaling the payout operation
The right license follows the activity—not the business name, interface, or number of recipients. Classify the funds flow, establish which permissions cover it, and then assign operational responsibilities.
Once that foundation is clear, evaluate Payouts.com payout automation for coordinating payment workflows and reconciliation. Start with a documented India corridor and a verified provider scope; expand only when the next flow has passed the same review.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
34 commentsRelated resources
Cross Border Payments Companies in India: A Buyer’s Guide
India-focused payment providers solve different problems: export collections, import payments, and international payouts. Build your shortlist around the legal payment flow and the evidence your finance team needs—not a generic provider ranking.
Enterprise Payment System: Scale Across Legal Entities
An enterprise payment system must do more than send payments globally. It must preserve entity-level authority, funding boundaries, and accounting evidence as the business scales.
Payment Card Industry Compliance Requirements for Payouts
PCI obligations follow card data and the systems that can affect its security—not simply the direction money moves. Here is how global payout teams can define scope, choose a validation path, and prevent unnecessary exposure.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The piece correctly emphasizes that using a bank API or NEFT doesn't establish permission for the underlying business, but in practice this is where most early-stage fintech teams get tripped up. We built an entire India vendor payment workflow assuming our banking partner's FEMA compliance covered us, only to discover during a compliance audit that we needed our own documentation trail proving each payment met permitted-purpose criteria under Schedule III.
The framing around 'whose obligation is being paid' and 'who controls the funds' is spot on. We made the mistake of designing our payment flow first and then trying to reverse-engineer the regulatory fit, which wasted three months and required a complete architecture redesign. Starting with the economic substance of the transaction and then mapping to the right authorization category would have saved us a lot of pain.
We did the exact same thing. Built the entire settlement flow assuming our domestic PA auth would stretch to cover import payments, then had to tear out the pooled account model and separate everything by scope. The article's point about mapping each account to its permitted function would have saved us a quarter.
Same here. We burned six weeks and two architecture revisions because our engineering team assumed the payment rail determined compliance scope. It doesn't. The economic substance and control points do, which means legal and finance need to be involved from day zero, not after the API contracts are signed.
The distinction between payment aggregation authorization and FEMA foreign exchange authorization is something our compliance team completely missed in initial scoping. We assumed our domestic PA license provider could just extend to handle export collections for our marketplace, but turns out the cross-border scope is a separate authorization track with its own capital and operational requirements.
We ran into the exact same assumption issue. The cross-border PA-CB authorization is a completely separate scope application, and even then it's restricted to specific directions—import aggregation versus export aggregation aren't interchangeable. Ended up needing a different provider relationship entirely for our export settlement flow.
We ran into the exact same assumption issue. The cross-border PA-CB authorization is a completely separate framework with its own scope limitations. Our provider had to apply fresh and we had to redesign the entire collection flow because the domestic authorization just doesn't extend.
The biggest operational headache from this structure is that you need separate banking and reconciliation workflows for each regulated category. We discovered this when trying to build a unified treasury dashboard for our India subsidiary—domestic settlements can't share a pool with export receipts, forex conversions require a different counterparty, and the moment you touch stored value the compliance burden doubles. Would love to see a follow-up on how to actually architect the back-office processes when your payment flows span three different RBI frameworks.
We ended up maintaining three separate ledger mappings just for India operations—one for domestic merchant settlements, one for export collections, and another for FX conversions. The reconciliation overhead is real, but trying to commingle those pools would have put us offside with our banking partner's compliance team.
Exactly this. We hit the same wall when trying to consolidate cash visibility. The recon burden is real—you basically need to treat each flow as a separate entity from a control and reporting standpoint, even if it's all under one legal entity. Have you found any workarounds for at least pulling consolidated reporting without commingling the actual funds?
The article says to document whose obligation is being paid, who controls the funds, payment purpose, and direction before picking a route. That's helpful in theory but in practice we're a B2B marketplace with mixed flows—some export receipts for sellers, some domestic settlements, some refunds that cross categories. Has anyone actually mapped a structure like this without splitting into separate legal entities per flow type?
You'll likely need separate authorization paths for each flow type. The domestic settlements might stay under your existing PA authorization, but export receipts for sellers would need PA-CB coverage. Refunds get even messier because the regulatory classification depends on whether you're refunding a domestic aggregated payment or unwinding a cross-border collection. We ended up having to involve three different licensed entities to handle a similar mixed model.
You'll need to split those into separate regulatory paths. The export receipts likely require PA-CB authorization, domestic settlements fall under standard PA, and refunds need to match the original flow's authorization. A single pooled account structure won't work here without violating the scope limits described in the article.
The framework here is solid but I wish there was more clarity on timeline expectations. If we're looking at a PA-CB route for export collections, what's the realistic authorization timeline from RBI once you hit the net worth and incorporation requirements? We're trying to decide whether to build this in-house or just layer on top of an existing authorized provider for the next 18 months.
Timeline is typically 12-18 months from application submission if your documentation is complete, but that assumes no material objections during RBI review. The net worth piece is table stakes—the real delay is usually the operational readiness assessment and any back-and-forth on your settlement account structure. Factor in at least 6 months of pre-filing prep with counsel before you even submit.
Timeline is typically 12-18 months from application submission if your documentation is complete, though I've seen it stretch to 24 months when RBI requests additional clarifications on the business model. The real question is whether you can afford to wait that long or if you need to route through an existing licensed aggregator in the interim.
The section on 'whose obligation is being paid' is the single most important framing question here. We lost about six weeks trying to evaluate licensing routes before realizing we were conflating our own payables (supplier invoices we owe) with customer funds we collect and forward. Once we separated those two flows the regulatory path became much clearer, even if still complicated.
Same mistake here. We spent almost a month building a compliance matrix that mixed corporate payables with marketplace seller settlements. The moment we split those two flows on paper, the licensing path became much clearer and we saved a lot of back-and-forth with counsel.
We had the same realization but it took us even longer because our finance team was using the term 'remittance' for everything—supplier payments, customer refunds, and actual cross-border collections. The moment we mapped each flow to the three questions in the article (whose obligation, who controls funds, payment purpose) the licensing paths became obvious.
The MTSS section is particularly useful because we keep getting pitched on 'contractor payment solutions' that blur the line between consulting invoices and personal remittance structures. The economic purpose framing helps push back on vendors who claim it's all the same as long as the recipient is an individual.
We had the same issue. The vendor kept insisting that because the contractor is filing ITR as an individual, MTSS should work. Our counsel shut that down immediately—the nature of the underlying service contract controls, not the tax filing status of the recipient.
We had the same issue. The vendor kept insisting that because the contractor is filing ITR as an individual it qualifies as personal remittance, but our external counsel pushed back hard on that. The determining factor is the nature of the payment obligation, not just the tax residency or legal form of the payee.
The cross-border PA scope distinction is tricky in practice. We're a SaaS company collecting from Indian merchants for cloud services hosted abroad, and our counsel told us domestic PA authorization wouldn't cover it because the service delivery happens outside India. Ended up needing to structure through an overseas entity with local collection, which added two months and a lot of FX friction.
We had almost the exact mirror situation with payouts to overseas freelancers. Counsel was very clear that if the contract is for services delivered abroad, even if the beneficiary happens to have an Indian bank account option, it doesn't transform the payment into a domestic settlement that a standard PA authorization would cover.
We ran into something similar on the export side. Domestic PA authorization explicitly doesn't cover cross-border aggregation, and the PA-CB framework requires you to specify whether you're doing import payments, export collections, or both. The service location matters more than where your customer is incorporated.
The point about net worth requirements not being a license purchase price is important. I've seen too many pitch decks where founders budget for the 15 crore as if it's a one-time fee, when it's actually capital that needs to sit in the business. That changes the funding math completely.
Exactly. Plus that net worth requirement scales up to 25 crore by year three, so you need to plan for that ramp in your Series A. It's operational capital, and if you're burning through it for growth, you're out of compliance before you know it.
Exactly. Plus that net worth requirement scales up to 25 crore by year three, so you need to model the funding tranches accordingly. Most early-stage VCs aren't prepared for that kind of capital efficiency drag when the money has to stay locked in net worth instead of being deployed for growth.
We tried to map our marketplace seller payout flow to the PPI route last year and hit a wall exactly where this article predicts. The RBI classification turned on whether we were settling merchant obligations or issuing stored value, and our counsel made it clear those are completely different regulatory paths. Would have saved us six months if we'd understood the whose-obligation-is-being-paid question from day one.
Same conclusion here. Our legal team spent two months on this and the distinction comes down to whether you owe the money yourself or you're holding customer funds to disburse. The regulatory treatment is night and day.
Same conclusion here. Our legal team spent two months on this and the distinction comes down to whether the instrument carries a stored balance that can be used for future purchases versus a pure settlement account. The moment you hold funds that aren't tied to a specific completed transaction, you're in PPI territory regardless of how you label it internally.
Is there any clarity yet on whether a company using a licensed PA-CB provider to pay overseas suppliers needs its own authorization, or does the provider's license cover that leg? The article says the activity matters more than the rail, but I'm still unclear where the compliance boundary sits when you're the corporate buyer rather than the platform.
The provider's license covers their activity, not yours. If you're just paying your own supplier invoices through their platform, you're their customer and the import documentation burden is still on you. But if you're collecting funds from others and then routing those payments through the PA-CB, that's when you cross into needing your own authorization.
The provider's license covers their activity, not yours. If you're just paying your own supplier invoices through their platform, you're typically the customer, not conducting the regulated activity yourself. But if you're collecting funds from your own customers and then moving them overseas, that's when you cross into needing your own authorization. The distinction the article makes about whose obligation is being paid is the key question your counsel should answer.