Classify each corridor by fund movement first, then choose your PA-CB path. For foreign platforms entering India, the practical sequence is: map payer and beneficiary locations, confirm whether activity is inward, outward, or both, and test whether you are aggregating and settling merchant funds. If yes, treat RBI authorization as a pre-launch gate for non-bank entities. Keep one signed flow map and one controlled decision log linking legal basis, FEMA artifacts, and product restrictions before any customer-facing activation.
For many foreign platforms, the first India decision is scope, not speed. You need to identify the correct RBI Payment Aggregator - Cross Border, or PA-CB, route before launch work spreads. RBI introduced this category on 31 October 2023. The PA Directions took effect on 15 September 2025.
If you own compliance, legal, finance, or risk, focus on a decision record you can defend later. That means confirming scope early, keeping licensing analysis separate from Foreign Direct Investment structuring, and documenting approvals in a form that can stand up to bank scrutiny and internal audit.
Classify the flow first. The framework distinguishes inward, outward, or both. Product labels alone do not determine scope, so document payer location, beneficiary location, and settlement path.
A creator platform, contractor network, or seller marketplace can look identical in the product UX but fall into different regulatory buckets once you trace the actual fund movement. If your roadmap includes both collection into India and payout from India, treat that as a two-way scope decision now, not a later add-on.
Use a one-page flow map signed by product and legal. It should show who pays, who receives, where funds move, who the merchant is, and whether each flow is an inward or outward cross-border current account transaction under FEMA that is not prohibited. Do not classify only by incorporation location; map the foreign exchange movement.
For non-bank entities, prior RBI authorization is described as required before starting payment aggregator activity. So the launch question is whether your model is truly outside aggregation, or whether your contracts and settlement design place you inside aggregation and subsequent settlement of customer payments to merchants.
The 2023 circular was meant to move affected cross-border operators into the authorization framework instead of older market arrangements. If your operating assumptions came from older setups, re-test them before launch decisions harden.
Do that verification before any customer-facing rollout. Get a written position on whether your model involves aggregation and settlement, and whether the intended corridor is inward, outward, or both. Escalate when commercial positioning says "software-only" but onboarding, settlement terms, or treasury flows show payment facilitation.
Use a complete submission pack rather than fragmented internal opinions. At minimum, include the business model, payment flow, ownership structure, financial position, merchant onboarding procedures, and technology systems.
Treat Foreign Direct Investment structuring as a parallel workstream that can affect timing and evidence, not as a substitute for scope determination. Secondary materials reference screening items such as ₹15 crore net worth rising to ₹25 crore by March 31, 2026, and a ₹25 lakh per-transaction cap in some discussions. Confirm current applicability against primary RBI text and your use case before product sign-off.
Keep one controlled decision log. If counsel, your Authorised Dealer bank, and internal stakeholders are not working from the same fact set, escalate before launch.
This pairs well with our guide on SaaS Accounting Software Evaluation: What Payment Platforms Need Beyond Standard GL Features.
Choose your India launch path from actual money movement, not your org chart. This section is for teams handling contractor, seller, or creator flows that may fall into scope, not for teams looking for informal workarounds outside RBI expectations.
Start by mapping each real flow as inward, outward, or both before you lock product scope. Classify using who pays, who receives, beneficiary location, and settlement path, not labels like marketplace, creator tool, or contractor platform.
If your roadmap includes both collections into India and payouts from India, treat it as a two-way case now. Inward and outward payment accounts cannot be mixed, so early misclassification can create redesign work later.
Use a direct test: do you collect customer payments for merchants and then settle funds to them? If yes, you are likely in Payment Aggregator territory, even if the commercial description uses lighter language.
That distinction matters. Non-bank entities are described as needing RBI authorisation before starting business in India, and operating without authorisation is described as a violation under the Payment and Settlement Systems Act. "Software-only" framing may not hold once operations show fund handling.
Entity structure matters, but control readiness is the practical filter. Check whether your setup can support the expected evidence and controls, including a statutory auditor certificate confirming net worth and an AD bank route for forex processing.
Set one gating checkpoint before product build expands. Legal, finance, and product should sign the same flow map and scope note. If expected ticket sizes may test the cited ₹25 lakh per-transaction cap discussed in related materials, escalate before pricing or launch commitments go out.
Launch pressure should accelerate decisions, not change classification. One cited checkpoint says the application should be filed at least 30 days before starting business, so a tight launch date is a reason to decide sooner.
Use a simple rule: if the flow is not clearly mapped and documented, pause. Once scope is explicit, the operating options become much easier to evaluate.
Start with transaction direction, then choose the operating mode. Teams often get this backwards by building collections, payout, and settlement flows before confirming whether scope is inward, outward, or both under the Master Direction.
The first three options map to PA-CB license directions. The last two are internal operating stances, not formal RBI license categories.
| Option | Best for | Pros | Cons | Key dependencies | Pre-approval caution (internal, not RBI-defined) | Escalation trigger |
|---|---|---|---|---|---|---|
| Inward route | Platforms collecting money into India for India-based exporters or sellers | Clear fit for inbound flows and simpler initial scope control. | If outward flows are added later, redesign risk increases. | Checkpoint: validate the flow as inward against the Master Direction (15 Sep 2025) and map required FEMA compliance controls. | Do not go live on an "assumed approval" basis while scope is unresolved. | Escalate if any near-term flow pays non-India beneficiaries or creates two-way movement. |
| Outward route | Platforms sending money out of India to foreign merchants | Keeps legal, product, and controls focused on outward movement. | Does not cover inbound collections into India. | Checkpoint: confirm the flow is outward under the Master Direction (15 Sep 2025) and map required FEMA compliance controls. | Do not launch live outward flows while direction classification is still unresolved internally. | Escalate if refunds, disputes, or seller flows create inbound receipts into India. |
| Two-way route | Platforms with real two-way corridors in near-term scope | Reduces rework when both directions are genuinely required. | Higher control and operating complexity from day one. | Checkpoint: document both directions as real requirements under the Master Direction (15 Sep 2025) and map FEMA compliance controls for both legs. | Do not use vague "future intent" to justify premature live operations. | Escalate if product and finance cannot keep direction-specific controls and reporting defensible. |
| Pre-license Foreign Direct Investment setup | Foreign-backed teams doing entity/readiness work before payment operations | Can support internal setup planning before launch decisions. | FDI sequencing or documentation requirements are not established in this grounding pack. | Checkpoint: treat this as pre-operational structuring only; separately validate payment activity against the Master Direction (15 Sep 2025) and FEMA requirements. | Do not treat FDI/entity setup as approval to start live aggregator payment operations. | Escalate if go-live decisions are being made from setup completion alone. |
| Hold-launch-until-approval mode | Teams with unresolved scope or interpretation risk | Prevents avoidable compliance and rework risk while scope is clarified. | Slower commercial start. | Checkpoint: classify scope using the 31 Oct 2023 PA-CB circular and 15 Sep 2025 Master Direction, then close open FEMA interpretation questions. | No customer-facing activation while approval status, direction, or interpretation is unresolved. | Escalate when legal cannot give a clear direction call or internal assumptions conflict. |
AD-bank coordination requirements are not established in this grounding pack and should be confirmed separately.
Choose scope from actual transaction direction, then build around it. Teams often overbuild product before confirming license scope, then unwind payout logic, terms, and reporting at high cost.
A practical check is to classify a sample of planned launch transactions by payer location, beneficiary location, and settlement direction. If several samples do not fit the chosen scope, pause and re-scope before making launch commitments.
Also avoid carrying over assumptions from the older OPGSP model since 2010. Scope was narrower, service exports were largely excluded, import transactions were capped at $2,000 per transaction, transaction fees were reported at 3-7%, and settlements were reported at 2-5 business days. Decisions here should be based on the current licensing perimeter, not that earlier framework.
As of January 2026, 19 entities were reported as fully authorised for these licenses. That points to an active licensing boundary, not a label to fix after launch.
If your launch is built around overseas customers paying India-based sellers, exporters, or service providers, an RBI-authorised PA-CB route focused on inbound collections is usually a clean starting option. It keeps scope to inbound collections, which can make control mapping easier while you line up compliance, FEMA handling, and bank operations.
Name: Inbound PA-CB route (working label) Brief description: A cross-border aggregation route focused on money coming into India for India-based beneficiaries. Key differentiator: It fits a one-direction export collection model, so you can map controls to inbound activity instead of designing for broader flows on day one.
Using a licensed partner is described as a default path for keeping India inflows compliant, and authorization is already being used in practice for overseas collections for Indian exporters. Public reporting on Jan 09, 2026 also showed one operator receiving final authorization after in-principle authorization in January 2025, which suggests this approval path is active in practice.
A clear fit is a platform collecting from global clients and settling to Indian sellers where the settlement direction stays consistently inbound. If your launch does not include payments to foreign merchants, creators, or offshore vendors, this route may be easier to defend.
The main risk is future scope drift. If your roadmap later adds outward legs, for example vendor payouts or offshore disbursements, you may need to redesign the model and controls for that expanded scope. The route choice can also affect unit economics, since FX spreads, settlement lags, and potential withholding-tax exposure can erode margins if the model is mismatched.
For a step-by-step walkthrough, see India Equalisation Levy: What Foreign Platforms Must Pay on Digital Advertising Services.
Where the product is mainly money leaving India to pay non-India beneficiaries, PA-CB Outward can be a clean fit. It keeps controls aligned to outward settlement instead of stretching an inward model to cover a different transaction direction.
Name: PA-CB Outward Brief description: A Payment Aggregator - Cross Border route for outward cross-border transactions from India-facing flows to non-India beneficiaries. Key differentiator: Clearer ownership for outbound compliance and operating risk in a one-direction model.
For non-bank operators, PA-CB services require RBI authorisation. The cited cross-border PA circular summary also describes separate Import Collection Accounts and Export Collection Accounts, so a single pooled account design is a practical red flag at the planning stage.
This route is strongest when settlement direction is consistently outward. A typical fit is an India-origin platform paying foreign merchants or service providers, with controls built around that outbound lane.
The main upside is control clarity for outbound operations. The main downside is scope fragmentation. PA-CB Outward on its own may not cover inward collections into India, so mixed-direction roadmaps can require a broader licensing strategy. Public reporting has also described at least one in-principle approval as covering both export and import flows, which is a practical reminder not to over-narrow if two-way corridors are near-term.
Treat this as an operating-control decision, not a paperwork exercise. PA-CB applicants are expected to meet broader requirements across governance, customer grievance handling, dispute management, and technology standards.
If your platform will handle both receipts into India and payments out of India within the next planning cycle, PA-CB Inward and Outward can be a lower-rework choice.
Name: PA-CB Inward and Outward Brief description: A two-way PA-CB operating scope for platforms that need both inbound and outbound India-linked cross-border flows from launch or soon after. Key differentiator: Fewer structural gaps when your product includes both collections and payouts across jurisdictions.
The main benefit is avoiding a second operating redesign when both directions are already on your roadmap. One fit is a creator or contractor platform that receives funds into India and also makes payments out of India tied to the same platform activity.
That scope decision matters under the Reserve Bank of India's Master Directions on Regulation of Payment Aggregators, 2025, which includes "11. Specific Directions applicable to PA - CB" and is effective immediately unless stated otherwise. For a two-way model, document this scope clearly in your application narrative, bank coordination, internal approvals, and control ownership map.
The tradeoff can be a higher implementation burden. The Master Direction names control areas you will need to operationalize across both directions: security, fraud prevention and risk management, reports, due diligence, and escrow accounts.
If both directions are in scope for your next planning cycle, consider choosing the two-way route early to reduce dual migration risk across product, compliance, banking, and customer communications.
If your foreign parent needs to fund India setup before go-live, use that phase for corporate setup and license preparation only, not partial operations.
Name: Pre-license capitalization before operations Brief description: A foreign-backed setup phase to prepare the India entity, define PA-CB scope, and prepare application evidence before any regulated activity starts. Key differentiator: It creates preparation time, but does not by itself establish operating permission under a PA-CB license.
This option is most useful when your team still needs to lock scope before building payment flows. A secondary source describes three PA-CB types: Inward, Outward, and Inward and Outward. Use pre-license time to map your real flow direction and align product, compliance, and bank coordination to that target state.
Set the boundary in writing and keep it strict. Do not assume pre-approval permission for merchant onboarding, PA escrow activity, or customer-fund handling. If your plan includes Foreign Direct Investment (FDI), treat that as a separate legal and AD-bank workstream; this grounding pack does not establish a specific pre-license FDI sequence or operating permission.
Use this route to prepare cleanly, but keep customer-facing payments functionality disabled until your licensing path and bank coordination are confirmed.
If ownership structure, flow direction, or regulator classification is still unclear, pause launch before any customer-facing activation. Do that when core structure questions remain unresolved, when financial-services classification is unsettled, or when flow design could map to more than one model.
Name: Hold-launch-until-approval mode Brief description: A deliberate hold until your team can document regulator scope, authorization path, and legal sign-off. Key differentiator: It reduces the risk of drifting into activity that could be treated as payment aggregation before your position is clear on authorization under the Payment and Settlement Systems Act, 2007 and your intended authorization route.
A grounded checkpoint is simple: confirm which regulator governs the specific activity before go-live. If your internal scope matrix still has open items for RBI coverage, authorization scope, or overlap with older OPGSP-related norms, you are not ready to activate.
Use a written pre-release classification memo. At minimum, align legal, compliance, and finance on the same product description, the authorization path being assessed, and whether overlap risk exists with older OPGSP-related norms. If those teams cannot sign the same description, freeze launch and escalate.
A common risk is partial rollout while the legal basis is still disputed. If ambiguity remains, pause, escalate, and preserve the decision trail. Because one industry guide cites a possible 12 to 24 month authorization timeline, plan for delay rather than forcing an unclear launch.
Build the evidence pack before you polish the application. Otherwise you end up defending decisions after launch instead of verifying them before launch. A common failure mode is simple: scope, legal basis, FEMA artifacts, and KYC records sit in separate inboxes with no controlled register tying them together.
Use one controlled register as the record of each material decision, with one owner, one version, one approval date, and one effective date. For each flow, map controls to these named anchors: processing-boundary choice (where relevant), Payment and Settlement Systems Act, 2007 basis, FEMA compliance artifact, and KYC policy record.
A common source of rework is documentation drift, not bad intent. When approvals are split across email, chat, and meeting notes, teams may not be able to show which exact flow was approved, by whom, and under which version.
Your register can be lightweight, but it should still capture the basics: flow name, entity, selected scope, legal basis note, linked FEMA artifact, linked KYC policy version, finance owner, product restriction, approval status, approval date, and effective date. This keeps the legal anchors operational. The Master Direction is issued under the Payment and Settlement Systems Act, 2007 and also cites FEMA, 1999 powers. Your memo should tie those anchors to the exact live flow, not just list them as background.
Version discipline matters. The Directions state they are effective immediately unless a provision says otherwise, so keep final versions in the pack and clearly retire consultation-era drafts during launch preparation.
These are internal operating gates, not RBI-prescribed stage names.
| Stage | Focus | Minimum control outcome | Rework prevented |
|---|---|---|---|
| Pre-incorporation | Scope and legal anchor | Written flow description, preliminary scope choice, and linked PSS Act/FEMA basis | Entity design or build work drifting ahead of classification |
| Pre-application | Evidence pack assembly | Flow docs, FEMA artifacts, KYC record, and named owners for reporting/bank coordination | Late document hunts and inconsistent application narrative |
| Post-application pre-approval | Change control | Scope freeze register with logged proposed changes and legal review routing | Silent scope expansion before approval |
| Go-live | Launch authorization pack | Final flow match check against approved register entry, with complete approval trail | Activating a flow no one can defend from records |
Use explicit internal checkpoints so the launch decision is auditable:
If you implement only one control, start with the register and require every artifact to point back to it. That is the fastest way to reduce scope drift and avoid costly rework later.
For the controls side of this work, see our guide on What Is an Audit Trail? How Payment Platforms Build Tamper-Proof Transaction Logs for Compliance.
Pre-approve the triggers that turn discussion into a stop or go decision. If an issue changes legal basis, reporting readiness, or feature scope, hold launch until one named owner records the decision.
Unclear operating-entity position. If the India-facing flow cannot be stated in writing as Indian entity, foreign entity, or split model, escalate to legal. Legal should record the entity, corridor, and assumed RBI scope, and compliance should confirm the linked CDD and AML control owner. No note, no launch.
Conflicting written guidance. Treat inconsistent written guidance as a no-go until finance, legal, and compliance align one documented position. Check that the funds-flow narrative, reporting fields, and purpose-code mapping match that position for the exact transaction type. This helps prevent avoidable friction in cross-border flows.
Ambiguous RBI scope reading. If legal and compliance cannot clearly classify the flow against applicable RBI requirements, escalate before build proceeds. Freeze scope-changing features until the stop or go decision is logged. If the chosen scope cannot be explained clearly in one paragraph, launch is not ready.
Adjacent regulator classification signal. RBI is the core regulator for banking, finance, and foreign exchange, and SEBI is relevant for public securities market questions. If group structure or affiliated activities raise non-payments classification questions, log a specialist-review flag rather than assuming the RBI payments analysis covers everything. Keep this as a short regulator-mapping memo with one owner and one approval date.
The practical win is not speed. It is getting the scope right before launch and escalating ambiguity early. If your model receives customer funds and later settles merchants, or takes temporary custody of funds, you are in Payment Aggregator scope. For non-bank entities, the supported position here is prior RBI authorisation before starting covered activities under the Payment and Settlement Systems Act, 2007.
Start with the corridor and fund flow, not the org chart. Map where customer funds are received, held, and settled, then use that map for control design. Keep the core distinction clear: gateway-only models that do not handle funds are described differently from models that receive and settle funds.
Do not treat entity setup or funding progress as an implied green light for live payment facilitation. Keep licensing-readiness decisions explicit and documented before activation.
Before activation, keep one controlled record of the business model, payment flow, ownership structure, financial position, merchant onboarding procedures, and technology systems. If those details are fragmented across email threads and tickets, readiness is weak.
A simple escalation test helps: where do customer funds sit, for how long, and who settles the merchant? If the answer points to your entity, escalate before launch. That is where scope mistakes become real exposure around fund safety, delayed settlement, and consumer protection.
Use secondary-market checkpoints as prompts, not final authority. Some sources cite markers such as applying 30 days before starting business, net worth figures of ₹15 Crores at application and ₹25 Crores by the end of the third financial year, and a ₹25 Lakhs per transaction cap. Treat these as review triggers. Confirm them against current RBI text and written advice for your model.
So the next step is straightforward: confirm your intended flow against your actual fund-receipt, custody, and settlement path, then complete a documented legal-compliance go or no-go review before any customer-facing activation.
Before go-live, run a final legal-compliance readiness review with your exact flow map and get a second set of eyes from Gruv's team.
No blanket yes-or-no answer is supported by the material here. What is supported is that RBI brought entities facilitating cross-border payment transactions for import and export of goods and services under direct regulation through its 31 October 2023 circular. Start by identifying which entity actually facilitates the flow, then verify license status on RBI’s public list of authorised Payment System Operators.
For RBI-facing classification, the supported category terms are export-only, import-only, and export-and-import. Treat those as your primary scope labels unless you have primary text confirming an exact terminology mapping to inward and outward language. The practical decision is whether you handle exports, imports, or both, because that drives operating scope and controls.
The provided excerpts do not establish a yes or no rule on FDI before approval. Treat FDI structuring as a separate legal workstream and confirm it in writing before relying on it in launch planning. If capitalisation steps and regulated payment-activity steps are being approved together, escalate.
The material here does not provide a complete, defensible list of prohibited pre-approval activities. Do not create an internal allowed or prohibited list without written legal guidance for anything that looks like live payment facilitation. If legal and compliance have not signed a clear boundary, pause rollout.
That position is not established by the sources provided. Treat any direct-foreign-operation assumption as an explicit escalation item, not a default. Require a short written position naming the operating entity, flow, and regulatory responsibility before go-live.
The excerpts only support part of a minimum pack: your selected PA-CB category, evidence for the minimum net worth criterion, and collection-account readiness. Keep a clear transaction-design record so per-unit values do not exceed the INR 25,00,000 per unit limit. Use RBI’s authorised PSO list as a status-check checkpoint where applicable.
Escalate when the entity position is unclear, guidance conflicts, or the flow cannot be confidently classified under the RBI cross-border payment aggregator regime. Escalate as well when the model may operate like a full-stack payment system, given the noted risk of operating without an AD bank’s protective shield. If the answer changes the licensing path, account structure, or who handles funds, internal interpretation is not enough.
A financial planning specialist focusing on the unique challenges faced by US citizens abroad. Ben's articles provide actionable advice on everything from FBAR and FATCA compliance to retirement planning for expats.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Includes 4 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Move fast, but do not produce records on instinct. If you need to **respond to a subpoena for business records**, your immediate job is to control deadlines, preserve records, and make any later production defensible.
The real problem is a two-system conflict. U.S. tax treatment can punish the wrong fund choice, while local product-access constraints can block the funds you want to buy in the first place. For **us expat ucits etfs**, the practical question is not "Which product is best?" It is "What can I access, report, and keep doing every year without guessing?" Use this four-part filter before any trade:
Stop collecting more PDFs. The lower-risk move is to lock your route, keep one control sheet, validate each evidence lane in order, and finish with a strict consistency check. If you cannot explain your file on one page, the pack is still too loose.