Every BES platform I have worked on treats fund switch as a routine feature. The participant picks a new allocation, hits confirm, and the UI says "your request has been received." Underneath that confirmation sits one of the most fragile pipelines in the entire pension product, and most operations teams only discover how fragile when a reconciliation breaks for an amount they cannot explain to the regulator.
This is not a calculation problem. The fund switch math is trivial: sell units in fund A at NAV_A, buy units in fund B at NAV_B, mind the rounding. The problem is sequencing — and sequencing is exactly what nobody revisits after go-live.
What a fund switch actually is in production
A single participant-initiated fund switch is not one transaction. It is a chain that typically touches:
- The participant portal (the request)
- The policy administration system (the contract state)
- The fund accounting system at the portfolio company (EGM)
- Takasbank for unit settlement
- The NAV publication cycle (T+1 in practice for most funds)
- The reconciliation engine that closes the day
Each of these has its own cutoff, its own clock, and its own definition of "today." The fund switch only works when all six agree. They rarely do.
The three sequencing assumptions that quietly fail
After years of owning this pipeline, the same three assumptions fail repeatedly, and none of them are in any design document.
Assumption 1: The contribution and the switch will not collide.
The classic break. A participant submits a fund switch at 14:30. A contribution from their employer's payroll file lands at 15:10, before the 17:00 NAV cutoff. The switch was queued against the pre-contribution unit balance. The contribution buys units in the old allocation. Now the switch executes against a balance that no longer matches what the participant saw, and the new contribution sits in a fund the participant explicitly moved away from forty minutes earlier.
There is no clean rollback. You cannot un-buy units at yesterday's NAV. You either eat the spread, push a corrective switch tomorrow at a different NAV (creating a second discrepancy), or have a very uncomfortable conversation with the participant.
Assumption 2: NAV cutoffs are aligned across funds.
They are not. A domestic equity fund, a Eurobond fund, and a gold fund inside the same BES plan can have different effective cutoffs because their underlying instruments price on different exchanges and time zones. A switch from a TRY money market fund into a USD-denominated fund submitted at 16:45 may execute the sell leg today and the buy leg tomorrow. For one business day the participant is in cash, exposed to FX move, and not invested in anything they chose.
This is documented nowhere on the front end. The UI shows one confirmation.
Assumption 3: The EGM reconciliation window will catch errors before they compound.
Reconciliation is end-of-day. Fund switches are intraday. If the switch breaks at 14:30 and reconciliation runs at 22:00, the participant has been told for seven and a half hours that they are in fund B when their units are still in fund A — or worse, in a half-state where the sell executed but the buy did not. If anything queries the balance during that window (a balance inquiry, a partial withdrawal request, another switch), it operates on inconsistent data and writes inconsistent data back.
Why standard rollback does not work
In most enterprise systems, a failed multi-step transaction triggers a compensating action. That model assumes the steps are reversible. Fund switches are not. Once units are sold at today's NAV and that NAV is published, you cannot pretend it did not happen. The portfolio company has executed in the market. Takasbank has settled. The only "rollback" available is a new forward transaction at a new NAV, which guarantees a price difference, which guarantees a P&L impact that has to be absorbed somewhere — usually by the pension company, occasionally by the participant, always uncomfortably.
This is why I push back when architects describe the fund switch flow as "eventually consistent." It is not eventually consistent. It is permanently inconsistent the moment any single leg executes in isolation.
What actually has to be designed for
The controls that work, from experience:
- Hard freeze on the participant balance the moment a switch is submitted. No contributions, no withdrawals, no second switch can execute against that balance until the first switch fully clears. This frustrates payroll teams. Do it anyway.
- Single effective cutoff per switch, not per fund. If any leg of the switch cannot execute at today's NAV, the entire switch defers to the next business day. Atomic at the participant level, not at the fund level.
- Intraday reconciliation checkpoints, not end-of-day. At minimum after the NAV cutoff of every fund involved in active switches.
- An explicit pending state in the UI. Stop telling participants the switch is done when it is queued. "Submitted, will execute at NAV of [date]" is not a worse user experience. It is an honest one, and it dramatically reduces the complaint volume when something does drift.
- A documented discrepancy absorption policy signed off by finance before launch, not improvised by operations during the first incident.
The part that gets missed
None of this is technically hard. The engineering is straightforward. What is hard is convincing the product and operations stakeholders that a feature they consider routine is, in production, a distributed transaction across four institutions with no shared clock and no global rollback. That conversation should happen at design time. It almost never does, because the fund switch screen looks so simple on the mockup.
The operational risk in BES is not in the products that look complex. It is in the ones that look simple and run thousands of times a day across a pipeline nobody owns end-to-end.