Cross-Border Payments: How to Build It

How to use this page

This page walks you through building one capability: moving money across India's border, legally, for goods or services. Receiving from overseas customers, paying overseas suppliers, or both.

It is the capability behind every Indian SaaS company, exporter, freelancer platform and marketplace that touches a foreign currency.

What cross-border payments actually are

Cross-border payments in India sit on three legal layers at once, and you cannot ignore any of them:

The three PA-CB categories, by direction of flow:

What it is not:

• Not a wire transfer with an API. The documentation obligations are the product.
• Not unlimited. See step 5.
• Not something you can route around. Using unauthorised channels is a FEMA violation, with penalties running to criminal prosecution for wilful breaches.

The whole journey, in one table

Steps 1 to 3 — direction, route and authorisation

Steps 1 and 2 — Direction, then route

Step 3 — Verify the authorisation

The same check applies to the accounts underneath. A PA-CB maintains separate collection accounts with an AD Category-I bank — one for imports, one for exports — and they must not be commingled, with each other or with the provider's own money. That separation is what keeps your export documentation intact, so your purpose codes and reconciliation continue to work. It is worth asking a provider to describe their account structure; a vague answer is informative.

Steps 4 to 6 — onboarding, the cap and the paperwork

Step 4 — Onboard the merchant

Standard KYC under the Master Direction, plus one thing domestic onboarding does not have: the FEMA purpose. You are not just establishing who they are, you are establishing what the money is for, because that determines whether it may cross the border at all.

Ongoing due diligence applies, and enhanced due diligence kicks in above ₹2.5 lakh per unit. That is low enough that for most B2B exporters it is the normal case rather than the exception — build it into the flow rather than treating it as an escalation.

Step 5 — Move it, inside the cap

from decimal import Decimal

# Per-unit cap on goods and services processed through a PA-CB.
PER_UNIT_CAP = Decimal("2500000")      # Rs 25 lakh
EDD_THRESHOLD = Decimal("250000")      # Rs 2.5 lakh -> enhanced due diligence

# NOTE THE WORD. The OPGSP limit it replaced was PER TRANSACTION. This one is
# PER UNIT of goods or services, and how a "unit" is measured is genuinely
# ambiguous -- the RBI has not defined it precisely and practitioners have been
# asking since the 2023 circular.
#
# Practical consequence: a Rs 35 lakh consulting engagement is NOT solved by
# splitting it into two payments. If it is one unit of service, it is one unit.
# Structuring invoices to duck the cap is the thing that looks like structuring.

def check_transaction(txn) -> dict:
    flags = []
    if txn["value_inr"] > PER_UNIT_CAP:
        flags.append({
            "block": True, "why": "exceeds_per_unit_cap",
            "action": "route via an AD bank directly, not by splitting the invoice",
        })
    if txn["value_inr"] > EDD_THRESHOLD:
        flags.append({"block": False, "why": "enhanced_due_diligence_required",
                      "action": "EDD on the counterparty before processing"})
    if not txn.get("purpose_code"):
        flags.append({"block": True, "why": "no_purpose_code",
                      "action": "a payment without a FEMA purpose is not a payment you can make"})
    if txn["direction"] not in txn["provider_categories"]:
        flags.append({"block": True, "why": "provider_not_authorised_for_direction",
                      "action": "export-only cannot process imports"})
    return {"allow": not any(f["block"] for f in flags), "flags": flags}

# WHAT TO CHECK
# [ ] above the cap, the answer is a DIFFERENT ROUTE, not a smaller invoice.
#     An AD bank can handle what a PA-CB cannot. Splitting to fit is the
#     pattern every AML system is built to notice
# [ ] "unit" is ambiguous. Write down YOUR interpretation, get it agreed with
#     your provider and your bank IN WRITING, and apply it consistently. An
#     inconsistent interpretation is worse than a conservative one
# [ ] EDD above Rs 2.5 lakh is on the COUNTERPARTY, and it takes time. Build it
#     into the flow, not as a blocking surprise at payment
# [ ] the purpose code is chosen from the RBI list at the point of the payment,
#     not guessed later by finance from the narration
# [ ] provider category is checked in code against the direction. It is a
#     one-line check and it prevents a whole class of failed payment

The gotcha nobody documents: the cap is per unit, not per transaction — a deliberate change from the OPGSP regime it replaced, and the RBI has not defined precisely what a “unit” is. For a physical good it is intuitive. For a ₹35 lakh consulting engagement it is not, and splitting the invoice is exactly the behaviour an AML system is designed to flag. The correct answer above the cap is a different route — an AD bank — not a smaller invoice. Write down your interpretation of “unit”, agree it with your provider and your bank in writing, and apply it the same way every time.

Step 6 — Document it

# A payment that settles is not the same as a payment that is compliant. The
# money arriving is the easy part; closing the regulatory entry is the work.

PURPOSE_CODES = {          # illustrative -- use the current RBI list
    "P0802": "software consultancy / implementation",
    "P0807": "business and management consultancy",
    "P1006": "advertising and market research",
    "P0103": "export of goods",
}

def remittance_record(txn, merchant):
    rec = {
        "direction": txn["direction"],               # INWARD | OUTWARD
        "purpose_code": txn["purpose_code"],          # chosen at payment time
        "amount_fcy": txn["amount_fcy"],
        "currency": txn["currency"],
        "amount_inr": txn["amount_inr"],
        "fx_rate_applied": txn["fx_rate"],
        "value_date": txn["value_date"],
        "counterparty": txn["counterparty"],
        "invoice_ref": txn["invoice_ref"],
        "contract_ref": txn.get("contract_ref"),
    }
    if txn["direction"] == "INWARD":
        # Export of services or goods. The AD bank reports into EDPMS, and the
        # entry stays OPEN until it is matched and closed. An unclosed entry is
        # a compliance item with your name on it, months later.
        rec["fira_required"] = True                  # Foreign Inward Remittance Advice
        rec["edpms_entry"] = "expected"
        rec["close_by"] = txn["value_date"] + realisation_window(merchant)
    else:
        # Import. Reported into IDPMS, and the entry closes against evidence
        # that you actually received what you paid for.
        rec["idpms_entry"] = "expected"
        rec["evidence_required"] = ["bill_of_entry" if txn["is_goods"]
                                    else "service_completion_evidence"]
    return rec

# WHAT TO CHECK
# [ ] FIRA is requested and STORED per inward remittance. It is the evidence
#     the money is export proceeds and not something else, and clients,
#     auditors and the tax authority all ask for it eventually
# [ ] EDPMS / IDPMS entries are TRACKED TO CLOSURE, not assumed closed. An open
#     entry is the single most common cross-border compliance debt, and it
#     surfaces as a bank refusing your next transaction
# [ ] the purpose code is picked at payment time from the current RBI list.
#     Reverse-engineering it from a bank narration months later is guesswork
# [ ] store the FX RATE APPLIED, not just the INR amount. Without it you cannot
#     audit the spread in step 7
# [ ] invoice and contract references are captured with the payment, because
#     closing an EDPMS entry needs the documents, not the payment record
# [ ] outward payments need evidence you received the thing. A bill of entry
#     for goods; something defensible for services

The gotcha nobody documents: EDPMS and IDPMS entries stay open until somebody closes them. The payment succeeds, the money is in the account, everyone moves on — and an entry sits in a monitoring system waiting for documentation. It surfaces months later as a bank declining your next transaction until the backlog is cleared. Track entries to closure as a first-class part of the product, not as something finance will sort out at year end, because by then the invoices are hard to find and the people who raised them have moved on.

Steps 7 and 8 — FX, reconciliation and reporting

Step 7 — The FX

This is where the money goes, and it is almost never on the pricing page.

A provider quoting “1% fee” may be applying an exchange rate two or three percent away from the interbank rate. The fee is visible and the spread is not, and the spread is usually the larger number. Build Sheet 05 records that all-in cross-border costs are frequently reported in the 5–7% range against a 3% headline, and the difference is almost entirely FX.

Step 8 — Reconcile and report

Three obligations that arrive together and are usually owned by nobody:

• Reconciliation. Foreign currency in, INR out, at a rate, on a date, with fees deducted somewhere. See Build Sheet 05 — the control-total discipline applies identically, with an FX leg added.
• EDPMS / IDPMS closure, tracked as a queue with an owner and an age.
• FIU-IND. Cross-border payment operators are reporting entities under the PMLA. Registration and reporting obligations follow, and Build Sheet 04 covers the mechanics.

What it costs

Three versions you could build

The starting version

Build: one authorised PA-CB provider matching your direction → purpose code captured at payment time → FIRA requested and stored per inward remittance → FX rate stored per transaction → a spreadsheet tracking EDPMS entries to closure.

It breaks when: a transaction exceeds the per-unit cap, or you start paying outward and your provider is export-only.

The proper version

Build: everything above, plus — an AD bank relationship for above-cap transactions → provider category checked in code against direction → EDD built into the flow above ₹2.5 lakh → a written, agreed interpretation of “unit” → an EDPMS/IDPMS closure queue with an owner and an age report → effective all-in rate computed per transaction and reviewed monthly.

Trade: the documentation machinery is real work that produces nothing visible until the day it is needed, and then it is the only thing that matters.

Becoming the PA-CB

Build: authorisation, ₹25 crore net worth, separate collection accounts, FEMA and FIU-IND reporting, merchant due diligence at scale.

Use when: cross-border payments are the product. Not to save on FX.

What goes wrong

Where to go next

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.