The two-source model

One customer journey. Two brokers see two legs. The ledger reconciles the two into a single deposit without double-counting.

The customer's journey

Customer INR  →  GlomoPay LRS  →  quote FX rate  →  USD  →  ViewTrade custody
                     │                                            │
                Records the INR-side facts:                Records the USD arrival:
                • PAN                                        • wire_in event
                • INR amount                                 • the cash deposit
                • TCS collected by AD bank                     posts here — ONCE
                • quote rate + Valura's FX spread
                • purpose code

Why two sources, not one

Because the money crosses currencies. GlomoPay is India's AD-bank-authorised LRS partner (INR side). ViewTrade is the USD custodian (dollar side). Neither alone tells the whole story — GlomoPay knows the INR amount and PAN and TCS, ViewTrade knows the USD wire that landed and its custody state.

The no-double-count rule

The USD deposit is posted once, from the ViewTrade wire_in. GlomoPay's paid event contributes only:

• The FX-spread revenue (Valura's margin on the conversion).
• The compliance audit row (INR, PAN, TCS, purpose code).

It never posts the deposit cash itself. So the sum of deposits in the ledger = the sum of ViewTrade wire-ins = the truth.

Per-customer reconciliation

Where the two legs meet: per customer, the sum of GlomoPay remittances should approximately equal the sum of ViewTrade wire-ins. Small residuals are custody fees. Big ones are worth investigating.

The reconciliation view surfaces:

• Matched — a remittance paired with a wire-in on the same customer within the amount + date tolerance.
• In-transit — a remittance sent, no wire-in yet (money still in flight).
• Unmatched funding — a wire-in with no remittance (a direct funding not routed through GlomoPay, or a remittance we haven't ingested yet).

See LRS ↔ ViewTrade tie-out.

What each source contributes

Data	Source	Where it lands
USD deposit (wire_in)	ViewTrade	Ledger cash + customer wallet
US trades	ViewTrade	Custody + securities liability
Dividends + WHT	ViewTrade Daily Ledger	Cash + WHT payable + dividend sub-ledger
INR amount, PAN, quote rate, TCS	GlomoPay	Audit table (drives LRS + tax reports)
FX-spread revenue	GlomoPay	4030 FX Spread Revenue
Live positions + prices	ViewTrade	NAV report (read-only, not posted)
Merchant balance	GlomoPay	Treasury view

What each source doesn't tell us

• ViewTrade doesn't know that a deposit came via LRS. It just sees a USD wire.
• GlomoPay doesn't know when the USD actually lands at ViewTrade — its view ends at the settlement handoff.
• Neither has a shared per-remittance reference we can trust for exact matching (see the tie-out page for detail). Per-customer tie-out is the practical signal.

Provisioning

The link between "GlomoPay customer" and "ledger customer" is set at provisioning time (from api-global). Without it, GlomoPay events arrive with a cust_* id the ledger can't map.