RTA feed automation guide
Read CAMS & Karvy Email Feeds. Automate Your Portfolio.
Turn authorised daily CAMS and Karvy/KFintech emails into a secure, auditable workflow for updating mutual fund holdings and portfolios.
Downloading daily RTA emails, copying spreadsheet rows and manually refreshing investor portfolios creates avoidable delays and reconciliation errors. The better approach is to automate the delivery-to-ledger process, while keeping the source data, validation rules and exception handling visible.
What are CAMS and Karvy email feeds?
CAMS and KFintech are registrar and transfer agents (RTAs) serving mutual funds. Many distributors receive transaction, investor, AUM or other reports through authorised mailback and subscription services. Teams often still call the KFintech service “Karvy feeds”, referring to its earlier Karvy branding.
A feed is not just an email to read: it is a dated data delivery that can update your investment platform. Its usefulness depends on the selected report, the funds covered, the distributor’s authorised access and the fields supplied. A transaction file, an investor master and an AUM statement answer different questions.
Choose the right reports before updating holdings
Start with a full opening position, then maintain it with subsequent changes. A daily transaction file alone cannot reconstruct investments made before your import history began.
| Report family | What it contributes | Important limitation |
|---|---|---|
| Investor / folio master | Client identity, folio ownership and available scheme references | A folio master is not a holdings balance. |
| Transaction feed | Purchases, redemptions, switches and other reported unit movements | Only posted, accepted transactions should change holdings. |
| Holdings / closing-balance snapshot | Units for a specified folio, scheme and as-of date | Confirm the report actually contains closing units. A rupee AUM total is not a substitute. |
| NAV and status reports | Dated valuation inputs, rejections, corrections and operational context | NAV changes value, not units. A SIP registration does not create an investment. |
For example, KFintech’s distributor manual describes subscription reports MFSD307 (transactions), MFSD310 (client-wise AUM) and MFSD311 (investor master), with formats and periodicity depending on the report. These are report identifiers, not universal column layouts. Confirm the current specification and whether your chosen holdings report includes unit balances. CAMS reports need their own documented mappings.
How to read the daily email and attachment
- Verify the delivery: check the authorised sender and delivery mailbox. Use the mail provider’s authentication results; a familiar display name alone is not proof of origin.
- Identify the report: read the provider, report family, requested scope, reporting period and generation timestamp. An email received today can contain yesterday’s data or a backfilled period.
- Open the attachment safely: follow the provider’s documented password or download process. Use only authorised links and files; never guess a password convention from PAN or folio data.
- Inspect its structure: confirm the actual CSV, delimited text, DBF, spreadsheet or archive format, encoding, headers and trailer totals. File extensions alone are not sufficient.
- Check a small sample: match a known folio and scheme to the source statement, inspect transaction dates and units, and compare the report’s record count or control totals where supplied.
This manual inspection establishes the rules for your parser. Save an approved, access-controlled sample and a versioned field dictionary rather than designing an import from the email subject alone.
Automate email reading without losing deliveries
Use a dedicated mailbox or label for approved feeds. Connect through an authorised Gmail API, Microsoft Graph or TLS-protected IMAP integration, depending on your email provider. Prefer OAuth and narrowly scoped permissions; store credentials and attachment passwords in a secrets manager, not source code.
- Discover messages: schedule polling or use supported change notifications. Match approved senders, expected report identifiers and the intended recipient. A notification should trigger a mailbox fetch, not directly modify holdings.
- Record receipt: store the provider’s message ID, attachment reference, received time and report period in an ingestion ledger. Use durable checkpoints and a configurable lookback window, not only the unread flag.
- Archive and queue: save the original attachment in encrypted, access-controlled storage and queue a processing job. Calculate a SHA-256 digest for each attachment.
- Decrypt and parse: use the authorised secret, validate the real file type, enforce archive size and extraction limits, and pass the content to the appropriate provider-specific parser.
- Validate and commit: stage rows, validate required fields and apply approved updates in a database transaction. Record row counts, errors and the processing result.
- Acknowledge completion: advance the processing checkpoint or move the message to a processed label only after the intended commit succeeds. Retry failures without reapplying successful imports.
Map CAMS and KFintech into one internal model
Keep separate parsers for each provider and report version, then translate their output into a shared model. The names below are illustrative internal fields, not official CAMS or KFintech columns.
| Internal field | Purpose | Validation |
|---|---|---|
| provider, distributor_id | Data origin and authorised tenant scope | Reject data assigned to an unauthorised distributor. |
| folio_number, investor_id | Investor and folio association | Preserve leading zeros; support joint ownership. |
| scheme_id, plan, option | Exact investment instrument | Map provider codes; distinguish direct/regular and growth/IDCW. |
| source_transaction_id, status | Transaction identity and lifecycle | Validate against provider rules and correction references. |
| effective_date, units, amount | Ledger movement and dated cash flow | Use explicit date formats and decimal arithmetic. |
| as_of_date, closing_units | Snapshot and reconciliation boundary | Check coverage and whether the snapshot is complete. |
Resolve holdings using the appropriate provider, AMC, folio and exact scheme/plan/option within the authorised tenant. Do not merge accounts solely by investor name or PAN, and do not match schemes by display name alone. Maintain reviewed mappings to your internal scheme master. Unknown schemes or changed headers must produce an explicit exception, not a guessed match.
Update units first, then value the portfolio
Maintain a posted transaction ledger and a derived position for each folio and scheme. Apply the provider’s transaction taxonomy: purchases and switch-ins generally add units; redemptions and switch-outs generally remove units. Handle reinvestments, transfers, mergers, splits and other adjustments according to their documented meaning. Cash IDCW payouts do not automatically add units.
Illustrative calculation: opening balance of 100 units + a posted purchase of 20 units − a posted redemption of 10 units = 110 units. At a valid NAV of ₹50 for the displayed valuation date, the holding is worth ₹5,500.
Use decimal values at the precision supplied by the source. Update valuation from a separately validated, dated NAV source and show that date to the investor. If a NAV is missing or stale, flag the valuation as unavailable or stale; do not silently substitute today’s date or zero value.
Portfolio value is the sum of the included, correctly valued positions. Invested amount, realised gains, tax lots and XIRR need transaction history and cash-flow rules; they cannot be reliably recovered from a single closing balance. A transaction request, payment initiation or SIP registration must not be treated as a completed holding.
Prevent duplicates and handle corrected transactions
Idempotency means processing the same delivery twice has the same result as processing it once. Use two levels of protection: message/attachment references and file hashes prevent identical file reimports; provider-defined transaction identity prevents the same economic transaction being applied across overlapping reports.
A file hash alone will not detect the same transaction inside a differently formatted or regenerated file. Likewise, date + amount + units is not a universally safe business key: two genuine purchases can share those values. If the provider’s identifier is missing or ambiguous, quarantine the affected records or use a provider-approved identity rule rather than silently deleting a potential duplicate.
Store rejected, cancelled and reversed records without counting them as new holdings. When a correction refers to an earlier transaction, retain the original audit record, link the revised version and recalculate the affected position. Do not append a corrected purchase as an additional purchase. Process out-of-order events using the report’s effective dates and lifecycle rules, not mailbox arrival order.
Reconcile positions before presenting them as confirmed
Compare ledger-derived closing units against a matching RTA snapshot for the same folio, scheme, coverage and as-of date. Reconciliation is not simply checking that an import job finished.
- Check missing files, unexpected record counts and header/trailer controls where provided.
- Compare closing units and investigate differences in timing, scope, reversals and scheme mapping.
- Keep separate freshness indicators for transaction imports, holdings snapshots and NAVs.
- Never interpret an absent folio in a partial report as a zero balance. Replace snapshot positions only when the selected report’s completeness and replacement semantics are established.
- Backfill missing periods, replay affected jobs safely and retain evidence of manual corrections.
Publish a batch only after required validation succeeds. Unresolved reconciliation differences must be resolved or visibly marked as pending, not hidden behind a successful-import message. Existing confirmed balances should remain traceable while delayed or disputed updates are investigated.
Keep the daily process secure and observable
Report successful, failed, duplicate and quarantined jobs separately. Alert on overdue expected reports, authentication failures, wrong attachment passwords, malformed files, unmapped schemes, reconciliation differences and stale NAVs. “No email received” is not proof that no transactions occurred.
Feeds contain sensitive investor information. Restrict access by role and distributor, encrypt stored attachments and database records where appropriate, mask identifiers in logs, and apply a documented retention policy. Do not send raw investor feeds to public AI tools or include credentials in support tickets. Spreadsheet exports also need protection against formula injection.
Test imports with authorised or redacted fixtures covering duplicates, reversals, wrong passwords, schema changes, incomplete snapshots and mailbox outages. Keep a manual review path for exceptions and an auditable replay process. Scheduling automates processing; it does not make delayed RTA reports real-time.
Official references and implementation checklist
Use the provider’s current documentation and your contracted report specification as the source of truth. Report names, fields and delivery arrangements can change.
- CAMS distributor mailback services — confirm access, available reports and delivery options.
- KFintech Distributor Services Manual — the December 2025 version documents subscription frequencies, report families, mailback encryption and supported formats.
- Approve report access, samples, initial balances and scheme mappings.
- Configure secure mailbox ingestion and provider-specific parsers.
- Implement staged validation, transaction identity and correction handling.
- Reconcile units and validate dated NAVs before presenting portfolio values.
- Monitor freshness, review exceptions and test recovery before unattended operation.
The result is a repeatable backend workflow: fewer manual downloads, traceable imports and consistent portfolio updates. Where it runs and who operates it should follow your organisation’s data ownership and access requirements.
Frequently asked questions
Are CAMS and Karvy/KFintech email feeds identical?
No. Report layouts, identifiers, encryption and delivery options can differ by provider and report version. Use separate parsers and a validated shared internal model.
Can daily emails update the complete portfolio automatically?
Authorised feeds can automate updates for the folios, schemes and periods they cover. Start from verified opening balances, process subsequent transactions and reconcile snapshots. Holdings outside that coverage require an additional authorised data source.
How do we avoid applying the same transaction twice?
Combine message and attachment tracking with provider-defined transaction identity. File hashes detect identical attachments, but overlapping or regenerated reports also need business-level deduplication.
Does a daily feed mean the portfolio is updated in real time?
No. Delivery depends on the selected report frequency and provider processing. Show separate transaction, holdings and NAV timestamps, and flag delayed or unreconciled data.
Build reliable investment workflows
Make daily portfolio updates a repeatable process.
Discuss your authorised RTA feed formats, reconciliation requirements and custom mutual fund application with Finvesto. Explore a customer-owned backend deployed on your infrastructure, with technical operations managed by Finvesto.
Talk to Finvesto