Skip to main content
MF Atlas sits between your application and a transaction backend (currently NSE). Most write operations are accepted synchronously and completed asynchronously — the API returns quickly, work continues with the exchange in the background, and the outcome reaches you by polling or webhook. These diagrams show the moving parts.

​
End-to-end onboarding

The happy path from credentials to allotted units.

​
Investor & UCC registration

POST /api/investors/v1/ returns 201 PENDING immediately. Atlas then registers the Unique Client Code (UCC) with the exchange and, if a fatca block was supplied, submits it right after — a FATCA failure is recorded but does not block REGISTERED. See Create an investor for the field reference and the provider_steps trail.

​
Order dispatch & lifecycle

POST /api/orders/v1/ validates and persists synchronously (202 PENDING), then a background worker dispatches to the exchange. A status-sync job later moves accepted orders to ALLOTTED and fills in nav, units and allotment_date. See Create a purchase order for status meanings and the cancel rules.

​
Payment & settlement cycle

A payment references one or more orders and a mode. It starts INITIATED; how the money moves depends on the mode. Completion arrives asynchronously via an exchange callback, which updates each linked order’s payment_status.
The number of business days from pay-in to allotment (or from redemption to payout) is set by the scheme and its RTA, not by MF Atlas. The only date window Atlas enforces is cheque dates: T−90 … T+3 calendar days.

​
Mandate registration

An ENACH mandate is usable as soon as it is REGISTERED; a PHYSICAL mandate needs the signed scan uploaded first. See Create a mandate for the first-debit lead time and the payment-time checks.