ETF Management System: Inside the Issuer's Daily Cycle

An ETF management system is the system of record for a listed fund’s daily cycle. It holds the basket and the units outstanding, runs creations and redemptions, strikes the NAV, produces the portfolio composition file and gets the fund’s files out before the market opens. This page describes that system from the issuer’s side: the operations team that runs the day. It is not a guide to buying ETFs, not a screener, not a portfolio tracker, and nothing here is investment advice.

An ETF issuer’s trading day has a shape no product page shows. An order cut-off passes. An authorised participant sends an instruction. A basket is confirmed in kind or in cash. A NAV is struck. Files leave the building. Each step depends on something another company produces on its own schedule, and the loop has to close whether or not every file arrives clean.

What follows is the whole of it: the records the system has to hold, the figures it calculates, what it publishes and to whom, the daily cycle in order, the counterparts that set the schedule, the failure modes worth naming, and three things you can measure this month without buying anything.

Key takeaways

An ETF management system owns what the listing creates (the basket and the PCF, the creation and redemption register, units outstanding) and it has to be right by the exchange’s open, not by the end of a reporting cycle.
Six records carry the whole thing. Hold one of them at the wrong level and no file built on top of it will be right.
The arithmetic is the easy part. What differs per fund is which price source, which cut-off and which version of the basket each calculation used.
The schedule belongs to files you do not control: the index provider’s, the custodian’s, the exchange close and the authorised participant’s deadline.
Reconstruction settles whether the system is doing the work. Rebuild a published NAV per unit from the system’s own records; an afternoon is a pass.

What an ETF management system is

It is the system of record for a listed fund’s operations: everything the listing creates, and everything the fund has to publish about it. It sits between the index provider’s file, the custodian’s records and the exchange, and it is where units outstanding and the basket are held together. That pairing is what makes an ETF an ETF.

The distinction that matters is units. A portfolio system tells a holder what their position is worth. An ETF management system tells the issuer how many units exist, what the basket behind them is worth, and what one unit is worth at the strike. Those three figures have to agree, and only the issuer has a reason to keep them agreeing.

Against the fund accounting system, draw the line by clock rather than by function. The fund accounting system owns the fund’s books and strikes the NAV on the fund’s cycle. This one owns what the listing creates, and it has to be right by the exchange’s open. The two share the data and not the deadline.

One more boundary, because it is where the ownership question usually gets muddy. Where a transfer agent or registrar keeps the investor register, the ETF system still owns units outstanding and the creation and redemption register. The register is an output of the cycle, not the input to it.

What it holds

Six records do nearly all the work.

An instrument master. ISIN, ticker, listing venue, share classes including any hedged class, the index tracked and the tracking rule, and the fund’s own creation unit size.
The basket and the PCF for one creation unit, with its cash component. This is the file authorised participants work off, and it is versioned by day.
Units outstanding and the creation and redemption register. Per order: the authorised participant, in-kind or cash, the basket version used, the settlement date and the units credited. Per day: the unit count the NAV was struck on.
The daily NAV record. NAV per unit, the strike time, the price sources, the holdings cut it was struck against, and who approved it.
Fee and expense accruals. Management fee, the accrual that runs into the TER, index licence and custody charges, each with its base and period.
Holdings, corporate-action and rebalance history. What the fund held on any given date, and why the basket changed when it did.

The test is the one the fund side applies. If the system cannot hold one of those six at the level the fund needs, no file built on top of it will be right — and the error turns up in a published figure rather than in a report nobody reads.

What it calculates each day

Six calculations run every day, and two funds tracking the same index can reach different figures on the same day and both be right, because their documents specify different cuts and sources. The arithmetic is not the hard part. The rule attached to it is.

Calculation	What the rule decides
PCF weights and the cash component	Rounding, minimum lot sizes, and whether the cash line absorbs the difference from the index
The value of the creation and redemption basket	Which price file, from which cut of the day, and what to do with a constituent that has not traded
The official NAV per unit at the strike	The strike time, the price sources, and the treatment of accruals at the valuation point
The indicative value published through the day	Which source feeds it, and how it stays consistent with the basket in force
Tracking difference and dividend accrual	The index’s total-return convention, and how the accrual is carried between distributions
The fee accrual that runs into the TER	The base, the day count and the period

What the system has to keep is the rule beside the calculation. A spreadsheet holds the arithmetic for a month and then needs somebody to remember which source was used and why. Six months later, when an authorised participant or an auditor asks why a figure moved, the answer has to come out of the system rather than out of a conversation.

A rule that is not written down is a rule that changes when the person who remembers it leaves. That applies to a fee base and to a tracking convention equally.

What it publishes

Publication is where the system leaves the building. Five outputs go out regularly.

The fact sheet, with the fund’s standard figures for the period.
The daily basket and holdings file, to authorised participants and the listing venue, before the market opens.
NAV history, so any past date can be looked up and explained.
Notices when a rebalance, a corporate action or a share-class change moves the basket.
The figures the fund’s documents and filings consume, read from the same NAV record rather than re-keyed into a template.

The PCF is the one to get right, because other people work off it. It is the securities, their quantities and the cash component an authorised participant delivers or receives to create or redeem units, and a dispute over a settlement turns on which version of the file was in force when the instruction was given. That is why the release time, and the short list of people allowed to reissue it, matter more than the arithmetic inside it.

The fact sheet is the output most often still assembled by hand, out of a performance file and a holdings file, one figure at a time. It looks right on the day and is impossible to reproduce a month later when somebody queries one number in it. The cost is not the hour of assembly. It is the half-day spent reconstructing a figure nobody can trace.

The daily cycle, in order

The cut-off passes. The basket in force for the day is fixed and versioned. Done looks like a timestamped version in the AP’s hands before the cut-off, not a file reissued afterwards.
The AP sends an instruction. Create or redeem, in-kind or cash, against the basket version in force. Done looks like an instruction matched to a version, not a message sitting in an inbox.
The basket is confirmed. Securities and the cash component are checked against the PCF, and settlement is scheduled with the custodian. A corporate action inside the basket is where this step stumbles.
The NAV is struck. Holdings valued on the fund’s stated cut, accruals applied, the total divided by units outstanding. Done looks like a record naming the price sources, the cut and the unit count.
Files go out. The next day’s PCF and holdings file to authorised participants and the listing venue, before the market opens.
Units outstanding are updated on settlement. The register takes the basket version used, the settlement date and the units credited. Until this lands, the denominator is a day behind.
The fact sheet and the reporting go. The published figures and the fund’s own documents read from the same NAV record. That is the point of having one.

What sets this schedule is not the calculation. Four things do: the exchange close, the index provider’s file, the custodian’s file and the AP’s own deadline for getting an order to its desk.

The index provider decides whether there is a basket to publish. The custodian decides whether the NAV is struck on a confirmed cut. The AP’s deadline decides whether the creation is today’s or tomorrow’s. A build that models the arithmetic and not those four dates will slip in production, whatever it did in testing.

Who it has to talk to

Eight connections carry the day. For each, what arrives and what breaks when it is late.

The index provider. Arrives: the constituent file, the weights and the rebalance calendar. Late: no basket to publish, so the day starts late and the PCF goes out late with it.
The custodian. Arrives: positions, cash and settlement confirmations. Late: the NAV is struck against unconfirmed holdings, and the difference surfaces weeks later as a break.
The transfer agent or registrar. Arrives: the investor register. Late: reconciliation work lands in the busiest hour of the day.
Authorised participants. Arrive: instructions and confirmations. Late: the order misses the cut-off and moves a day — a price exposure for them, a support ticket for you.
The listing venue. Arrives: the file requirements and the timetable. Late: the market trades without the fund’s own file in front of it.
Market-data vendors. Arrive: prices and corporate actions. Late: the strike uses a stale price that somebody has to defend months later.
The fund accounting system. Arrives: the fund’s books and the accruals the NAV depends on. Two systems, one NAV, two deadlines.
Identity and access. Not a business system, and the one that decides who may change a basket version or reissue a PCF.

The awkward connections decide the schedule more often than the calculations do. Every one of the eight belongs to somebody else, moves on their timeline and arrives in a format they chose. Most of the elapsed time in a build goes here, and it is the least interesting part to describe.

Where the work hurts

Five failure modes account for most of what goes wrong, and none of them is an arithmetic error.

A PCF corrected after authorised participants have worked off it. The missing control is versioning with a release time and a short list of people authorised to reissue, not a correction sent by message.
A basket that stops tracking after a corporate action. The index provider adjusts, the fund’s basket does not, and the tracking difference widens quietly for weeks. What is missing is an owner for the rebalance, named against the provider’s calendar.
Units credited before units outstanding is updated. The NAV per unit is then struck on the previous day’s denominator, and it is published before anyone notices. The control is one source of truth for the register and the denominator, updated on settlement.
A fact sheet assembled from two sources by hand. The figures are right on the day and impossible to reproduce a month later. An owner for the template, separate from the owner of the run, is usually what is absent.
A NAV strike only one analyst can reproduce. The process is written down; the exceptions are not. Until a second person can run the strike from the written process, the fund’s NAV lives in a head.

The test that settles all five is reconstruction. Take a published NAV per unit, pick a date, and rebuild it from the system’s own records: the prices, the cut, the accruals and the unit count. An afternoon means the system is doing the work; a week means a workbook is, and the published figure is only a summary of it.

Run the same test on the PCF. Pick a date and show which basket version went out, and who approved it. If that takes a search through mail, the control is not in the system yet.

What to do before you buy or build

None of this needs a vendor or a budget. Three things you can do this month.

Time one creation. Start at the AP’s instruction and stop when units are credited. Count the people who touch it and the systems it passes through. That elapsed time is the number any platform or build has to beat.
List the hand-typed figures. Follow one NAV from the index provider’s file to the published number and write down every place a figure is keyed in. Each one is a control currently running in somebody’s head.
Name two owners. One for the PCF and a different one for the fact sheet. Then ask each of them to reproduce last month’s version of their file out of the system, without opening a workbook.

What a build covers

The system you end up with is either a licence configured to your process or a build specified against it. We build and implement the second; we are not a licensed platform vendor. The delivery runs in six steps, documented on our fintech software development page: scope the workflow being replaced, prototype the hardest screen, map every system to integrate, two-week increments, a security and compliance review before launch, and hand over the code and the knowledge.

For an ETF the hardest screen is usually the basket and PCF screen, or the creation register. That is where versioning, rounding rules and approvals meet, and where a prototype tells you in a fortnight whether the specification is right. That is the shape of the platform we built for Motilal Oswal AMC, covering schemes, NAVs, purchases, redemptions and fact sheets. Our ETF platform work is the commercial side of the same subject; this article is the system side.

Common questions about ETF management systems

These six come up most often when an operations team maps its ETF cycle.

What does an ETF management system do?

It is the system of record for a listed fund’s daily cycle. It holds the basket and the units outstanding, runs creations and redemptions, strikes the NAV, produces the portfolio composition file and gets the fund’s files out before the market opens. Everything else in the operation reads from those records.

How is an ETF management system different from fund accounting software?

The difference is the clock, not the function. Fund accounting software owns the fund’s books and strikes the NAV on the fund’s cycle. The ETF system owns everything the listing creates, and it has to be right by the exchange’s open. They share the data and not the deadline.

What is a PCF, and why does its release time matter?

The portfolio composition file lists the securities, their quantities and the cash component an authorised participant delivers or receives to create or redeem units. Its release time matters because a settlement dispute turns on which version was in force when the instruction was given. Reissue rights belong to a short named list.

How is the NAV per unit struck each day?

The system values the holdings on the fund’s stated cut, applies the accruals and divides the total by units outstanding. Two funds tracking the same index can reach different figures on the same day and both be right, because their documents specify different price sources and cut-offs. That is why the NAV record names the sources and the cut.

Can the daily cycle run on spreadsheets?

For a month, yes. A workbook holds the arithmetic. What it cannot hold is the rule beside the calculation: which price source, which cut-off and which basket version each figure used. Six months on, when an auditor queries a number, the answer has to come out of the system rather than somebody’s memory.

What should you check before buying or building an ETF system?

Three checks, none of which needs a budget. Time one creation end to end and count the people and systems it touches. Write down every figure keyed in by hand between the index provider’s file and the published NAV. Then ask one owner each for the PCF and the fact sheet to reproduce last month’s version from the system.

← All articles