Arka Wealth
What Aarav sees
Good morning, Aarav
Resident IndividualInvest in GIFT City
USD · via LRSInvestments in GIFT City are made in USD under the RBI Liberalised Remittance Scheme. Rates are indicative and not guaranteed.
Fees & charges
Mutual Funds · GIFT City · USD
Past performance does not indicate future returns. Schemes are managed by IFSCA-registered fund management entities in GIFT IFSC and are denominated in USD.
GIFT City is an international jurisdiction, so your KYC is registered separately from your India-side records. It takes a minute and is reused for every future investment.
We sent a 6-digit OTP to +91 ••••• ••210, the mobile registered with that Aadhaar. It expires in 10 minutes.
Your KYC is registered with the IFSCA KYC Registration Agency and will be reused for every GIFT City investment.
Recent
USDHeld in your name with SBI's IFSC Banking Unit in GIFT City. Redemptions from any GIFT City scheme land back here.
Reference RMT-2026-8841207
Sped up for the demo — these steps run through to T+1.
Your bank never asks for your password over the phone or by email. Check the address bar before you type it.
Prototype — this is a mock of the bank's page. Nothing is submitted or stored, and Bharatomni never sees these credentials.
Pay from
Debiting ₹2,51,770 from your Indian bank
Your bank debits the amount and sends it to the AD bank that executes the outward remittance. Bharatomni never touches your INR account.
Good evening, Rhea
Non-resident Indian · UAEInvest in GIFT City
USD · funded from the UAEMoney moves from your UAE bank card to your GIFT City USD account over Mastercard Move. LRS does not apply — that scheme is for residents of India.
Fees & charges
Mutual Funds · GIFT City · USD
You are onboarding into GIFT City, an international jurisdiction, from outside India. Your passport and residence documents are checked here and then verified by the bank that will hold your account.
Four documents, read on the device. Nothing is stored on your phone.
The chip on your passport and Emirates ID is read directly, so the name and date of birth come from the issuer rather than from typing.
Bharatomni's score, earned across the checks below. The higher it runs the less risk the file carries — it sets which documents the bank has to see and whether a human reviews it.
What moved the score
7 checks67 and above is low risk and onboards as standard. 34 to 66 adds a compliance review before the account opens; below 34 is declined and never reaches the bank.
Your file went to State Bank of India's IFSC Banking Unit. It validated every document, accepted the risk score and opened your USD account.
Pay from
Debit cardsMastercard Move pushes the money to the bank account behind your GIFT City FCY account. It is a credit transfer, not a card purchase — nothing is charged as retail spend and there is no cash-advance fee.
To Bharatomni Payments · GIFT City IFSC · money transfer
Sent to the mobile registered with Emirates NBD. Any six digits work in this prototype.
Prototype — a mock of the bank's own screen. Nothing is submitted, and Bharatomni never sees this password.
Reference MOV-2026-4471182
Sped up for the demo — Mastercard Move settles within the hour on this corridor.
Your USD is sitting in your GIFT City account. Put it into the fund now, or pick a date and we will place the order that morning.
This takes a moment.
Folio PPFAS-IFSC-0044127
We will place the order on 1 September 2026.
Your USD stays in your own GIFT City account until then. Cancel any time.
Deposits are booked from money already in GIFT City. Add money first, then come back.
Rates are per annum, quoted by the IFSCA-regulated banking unit in GIFT IFSC and denominated in USD. The money never leaves the investor’s name.
Premature withdrawal is allowed at a reduced rate.
Your USD moved into a deposit account in your name.
Also available
OptionalOnce you have invested in a GIFT City scheme, your holdings and their value appear here.
Holdings
1 schemeBalances
USD equivalentOne account, a balance per currency. No rupees — GIFT IFSC is a foreign-currency jurisdiction, so the wallet holds only freely convertible currencies.
Hold some in another currency
From USDSend proceeds to
Reference RED-2026-0099412
Arka Wealth is a fictional wealth app. The shelf, the limits, the pricing and the rails behind every screen reach it through Arka's own backend.
One call draws the shelf
Hover a row to find it on the phone
Request
GET/v1/catalog/products
No consumer id, no body. This one header picks the shelf — partner authentication rides along and is settled between the two backends.
Response
143 ms200Raw JSON
LRS headroom
POST210 ms200/v1/limits/lrs/lookup
The PAN travels in the body, never in a path or a query string. Bharatomni asks its partner AD bank, which reads the consumer's LRS usage from RBI's CIMS returns — so a remittance he made through any other bank is already counted here.
Request body
Raw JSON
Send NRI or FOREIGN_NATIONAL instead and the same call returns a different
shelf on a different route. Nothing identifying crosses, so Arka caches one shelf per investor type.
Headroom is per PAN, not per app: CIMS carries what every AD bank has reported, so Arka cannot overshoot the annual cap by counting only its own remittances. The consumer record and the fee schedule are separate calls, in later steps.
Prototype. Endpoint shapes, rates, latencies and identifiers are illustrative — not a published API contract.
Request
GET/v1/catalog/schemes?product=mutual_funds
The same header, the same trust path. It also does the filtering: only schemes a resident Indian can buy under LRS come back, so Arka never writes eligibility rules of its own.
Response
168 ms200Raw JSON
Scheme detail
on tapidle/v1/catalog/schemes/{id}
Fetched only when Aarav opens a scheme. Tap one on the phone.
Raw JSON
The list carries everything the screen renders — NAV, return bands, expense ratio, minimums — so Arka stores no fund data and never goes stale. Detail is a second call because most people open two or three schemes, not twelve.
Prototype. Fund managers are real IFSCA-registered entities in GIFT IFSC; scheme names, NAVs, returns and holdings are illustrative, as are endpoint shapes and identifiers.
Start KYC (bank led)
POSTon submitidle/v1/kyc/sessions
Fires when Aarav taps Send Aadhaar OTP. The KYC is bank led — the IFSC banking unit is the entity of record, Bharatomni orchestrates it as KUA, and Arka never becomes the KYC holder. UIDAI sends the OTP; the PAN is checked against the Income Tax database.
Request body
Raw JSON
Verify OTP
POSTon verifyidle/v1/kyc/sessions/{kyc_id}/verify
The OTP comes back to Bharatomni, not to Arka. What returns is the identity Aadhaar confirmed, the PAN name match, the screening result and a KRA reference — the record every later step relies on.
Request body
Raw JSON
Bank led means the KYC record sits with the IFSC banking unit, not with Arka — one verification
the consumer can reuse across every product on the shelf. The Aadhaar number is never stored:
aadhaar.stored: false, only the offline eKYC reference is kept. The verified record also mints the consumer_id that the
product and limits calls in step 1 read from.
Prototype. No Aadhaar, PAN or OTP is really sent anywhere; identifiers, payload shapes and latencies are illustrative.
Price the remittance
POST184 ms200/v1/fx/quotes
Re-fires whenever the amount changes. Every line the consumer sees — the rate, each charge, the TCS and the USD he receives — is a field here, so the app does no arithmetic of its own.
Request body
Raw JSON
Re-check eligibility
POSTon continueidle/v1/remittances/eligibility
Checked again at the amount, not just at onboarding: headroom moves, KYC expires, and the scheme minimum applies to this ticket. A fail here stops the journey before any money moves.
Raw JSON
Create remittance
POSTon acceptidle/v1/remittances
Carries the declarations: source of funds, the FEMA declaration and the consent that lets the
AD bank file Form A2. Tick the GIFT City account box and open_ibu_account rides
along too — the IBU opens it on the KYC already registered, with no second onboarding.
Request body
Raw JSON
Fund it
POSTon payidle/v1/remittances/{id}/fund
The INR debit happens at the consumer's own bank; Bharatomni only records which account was chosen and hands the leg to the AD bank. No INR ever sits with Bharatomni.
Raw JSON
Debit confirmed
WEBHOOKafter loginidlePOST https://arka.example/hooks/bharatomni
The only call that runs the other way. The consumer authorises the debit on the bank's own page — Bharatomni never sees those credentials — and the bank's confirmation reaches Arka as an event carrying the UTR.
Raw JSON
FCY balance
GETon trackidle/v1/accounts/{id}/balance
The account the IBU opened, read back by the app. last_credit carries both legs —
the UTR from the India debit and the SWIFT or FCSS reference from the overnight
transfer — so a
consumer, an auditor or a bank can follow one payment end to end.
Raw JSON
How the money settles
OvernightTry a larger amount on the phone. Past ₹10,00,000 of cumulative LRS in the financial year the quote starts returning TCS at 10% on the excess — the rule lives in the rails, not in the app.
Prototype. Rates, charges and references are illustrative and bank marks are stylised. The net-banking screen is a mock of the bank's own page — nothing is submitted or stored. The TCS threshold and the USD 250,000 LRS cap follow the current rules, but this is not tax or regulatory advice.
Request
GET/v1/catalog/products
The same endpoint the resident journey calls. One header changes the shelf — the minimums, the funding rail and the disclosures all come back different.
Response
138 ms200Raw JSON
Funding capacity
POST186 ms200/v1/funding/capacity
There is no LRS here — Rhea is not resident in India, so no annual cap and no CIMS lookup. What limits her instead is the rail: Mastercard Move ceilings on the AE → IN-IFSC corridor, plus her card issuer's own.
Request body
Raw JSON
Send RESIDENT_INDIAN and the shelf comes back priced in INR with an LRS headroom
call beside it. The consumer's residence decides the rail, and the rail decides the limits —
Arka writes neither into its app.
Prototype. Endpoint shapes, rates, latencies and identifiers are illustrative — not a published API contract.
Start KYC (non-resident)
POSTon submitidle/v1/kyc/sessions
Fires when Rhea taps Add my documents. No Aadhaar and no PAN — residence, passport and a tax number instead. The response says exactly which documents this residence and this product require.
Request body
Raw JSON
Read the documents
POSTon captureidle/v1/kyc/sessions/{kyc_id}/documents
Each document is uploaded once and read on our side: the passport and Emirates ID chips are parsed, the address document is classified, the selfie is matched against the passport photo. What comes back is extracted fields plus a quality score per document.
Request body
Raw JSON
Risk score
POSTon checksidle/v1/risk/score
Bharatomni's own score out of 100, where higher is safer. Every check is returned with what it earned against its weight and the evidence behind it, so the bank and the partner can both see why — a score without reasons is not something a compliance team can accept.
Request body
Raw JSON
Hand the file to the bank
POSTon sendidle/v1/kyc/submissions
The documents, the extracted fields and the score go to the IFSC banking unit, which validates and verifies them itself and is the entity of record. Its decision comes back per document, with the account it opened.
Request body
Raw JSON
The score does not replace the bank's decision — it routes it. 67 and above goes straight through, 34 to 66 adds a named reviewer at the banking unit before the account opens, below 34 never leaves Bharatomni. Documents are held once and reused for every later product.
Prototype. No document is really read and no bank is really called; identifiers, payload shapes and latencies are illustrative.
Price the transfer
POST142 ms200/v1/funding/quote
AED to USD on the Mastercard Move corridor, held for 90 seconds. Change the amount on the phone and this re-prices — the rate and the fee are the rail's, not ours.
Request body
Raw JSON
Create the transfer
POSTon payidle/v1/funding/transfers
The quote id is passed in, so the consumer gets the rate she was shown. The card is a token — Arka never holds a PAN, and neither do we. The response asks for 3-D Secure.
Request body
Raw JSON
Authenticate
POSTon authoriseidle/v1/funding/transfers/{id}/authenticate
The password goes to the issuer, not to us — we carry the 3-D Secure result. Once it is authenticated the money is pushed to the receiving bank in GIFT City.
Request body
Raw JSON
Settlement
GETon settleidle/v1/funding/transfers/{id}
Polled, or delivered as the funding.transfer.settled webhook. It carries the
Mastercard trace, the amount credited and the FCY account it landed in.
Raw JSON
Four calls, no SWIFT and no A2. The money lands in an account in Rhea's own name with an IFSC banking unit; from there every later step — schemes, orders, deposits, redemptions — is the same as the resident journey.
Prototype. No card is charged and no transfer is made; rates, traces and latencies are illustrative.
Place the order
POSTon confirmidle/v1/orders
One endpoint for both choices. execution is either IMMEDIATE or a date —
a scheduled order books nothing and moves no money until that morning, so the USD stays in the
consumer's own account.
Request body
Raw JSON
Move the USD
POSTafter orderidle/v1/payments
Two book transfers inside GIFT IFSC: the consumer's FCY account to Bharatomni's multi-currency account, held as client money, then on to the scheme's collection account. No SWIFT, no FX — the money is already USD and already in the zone.
Request body
Raw JSON
Units allotted
WEBHOOKafter cut-offidlePOST https://arka.example/hooks/bharatomni
Allotment cannot be synchronous: the NAV is struck after the cut-off. The FME confirms, and Bharatomni posts the NAV, the units and the folio to Arka.
Raw JSON
Where the USD goes
Inside GIFT IFSCChoose Schedule instead and only the first call fires, with a date. Nothing is debited and no units are bought until that morning.
Prototype. NAV, units, folio and references are illustrative. The multi-currency leg assumes the IFSCA payment service provider authorisation Bharatomni has applied for; until it is granted the same movement is done by the banking unit as a book transfer.
Wallet balances
GET88 ms200/v1/wallets/wallet_mca_bomni
One e-money account under our IFSCA PSP licence, with a balance per currency. It is client money, segregated from ours, and it never holds rupees — GIFT IFSC is a foreign-currency jurisdiction.
Raw JSON
Hold it in another currency
POSTon convertidle/v1/wallets/wallet_mca_bomni/fx
A conversion inside the wallet — one balance down, another up. No payment leaves the account, so there is no rail, no SWIFT and no remittance: the money never moves, only its currency does.
Request body
Raw JSON
Holdings
GET156 ms200/v1/portfolio
Units, today's NAV and the cost basis in one read. The app shows a gain; it does not compute
one — unrealised comes back priced.
Raw JSON
Price the redemption
POSTon redeemidle/v1/redemptions/quote
Re-prices as the amount changes. The exit load applies because these units are under a year old — the rule sits with the scheme, and the quote applies it rather than the app. No TCS here: nothing is being remitted out of India.
Request body
Raw JSON
Place the redemption
POSTon confirmidle/v1/redemptions
payout decides the route. To the FCY account it is one book transfer inside the
zone. To India it goes through the multi-currency account, is converted, and leaves as an
inward remittance — the outbound journey in reverse.
Request body
Raw JSON
Proceeds credited
WEBHOOKon settlementidlePOST https://arka.example/hooks/bharatomni
The scheme pays out at T+1 and the credit lands after that, so this arrives as an event — with the destination account and the balance after.
Raw JSON
Where the money comes back
Two routesPrototype. NAV movement, charges and references are illustrative. Exit load follows the scheme's own terms; redemption proceeds are not subject to TCS, which applies to outward remittance.
Deposits on the shelf
GET142 ms200/v1/catalog/deposits?banking_unit=ibu_sbi
Filtered to the unit that holds the investor's FCY account. A deposit is a book transfer inside one banking unit, so quoting another unit's rates here would be quoting something the investor cannot book. Drop the filter and every unit's tenors come back.
Raw JSON
Deposit detail
on tapidle/v1/catalog/deposits/{id}
Fetched only when Aarav opens a deposit. Tap one on the phone.
Raw JSON
Maturity quote
POSTon amountidle/v1/deposits/quote
The banking unit computes the interest, not the app. Change the amount on the phone and the quote re-prices.
Request body
Raw JSON
Book the deposit
POSTon confirmidle/v1/deposits
The quote is accepted by reference. One call opens the deposit account and moves the
principal into it, at rail BOOK_TRANSFER — no wallet, no conversion.
Request body
Raw JSON
Move USD to the wallet
POSToptionalidle/v1/payments
Only if the investor asks for it. The same book transfer, pointed at Bharatomni's multi-currency wallet instead of a deposit account.
Request body
A deposit never touches the wallet. The money is already USD and already in the zone, so it moves between two accounts at the same banking unit and stays in the investor's name throughout.
Prototype. Rates, tenors and references are illustrative — not a published API contract.
What we need from banks
Every step of this journey needs something from a bank. This is the full list: accounts to open, approvals to grant, APIs to expose. Where there is no API, files and callbacks do the same job, more slowly.
The short version
Every integration
Prototype. Names describe capabilities, not any bank's product catalogue. The split between API, file and corridor rails will differ by bank.
API reference
Every call the journey makes, in the order it makes them. Partner backend to Bharatomni, server to server.
Prototype. Shapes, rates and identifiers are illustrative, not a published contract. Lists are trimmed to one element.