Every BES pipeline I have worked on carries the same silent scar. Somewhere between the payroll file landing in the SFTP directory and the participant seeing units in their account, there is a decision nobody wrote down: which NAV do we allocate against when the employer's file arrives after cutoff?
The honest answer is that most institutions do not know. The pragmatic answer is that they picked something years ago, hard-coded it into a stored procedure, and have been living with the consequences ever since.
Two Correct Systems, One Structural Gap
Payroll systems are built around employer obligations. A company running its cycle on the 25th of the month cuts a file when HR closes payroll, not when the pension fund's custodian strikes NAV. That file might land at 19:47 on a Friday, or Monday morning at 04:12 after a batch retry, or Tuesday afternoon because the SAP job hit a locked table.
Fund valuation is built around portfolio pricing. NAV strikes at a fixed cutoff — typically end of business day T, published T+1 morning after the custodian confirms prices. There is no flexibility. The cutoff is what makes the unit price defensible.
Both systems are internally correct. Neither was designed with the other in mind. And the bridge between them — the contribution ingestion layer that decides which valuation date a given payment belongs to — is where the entire integrity of the participant account sits.
The Silent Assumption
In most implementations I have audited, the rule is some variation of:
- If the file arrives before cutoff on day T, allocate at NAV(T)
- If it arrives after cutoff, allocate at NAV(T+1)
This sounds reasonable until you look at what "arrives" means. Arrives at the SFTP? Arrives in the staging table? Passes validation? Clears the manual approval queue that the operations team runs because 3% of records fail TCKN validation?
Each of those checkpoints can shift the effective allocation date by one to three business days. And each shift is a real financial event: the participant either gains or loses the market movement between the date they thought they were buying units and the date they actually did.
On a rising market, participants are quietly disadvantaged. On a falling market, the fund absorbs a loss it should not have taken. Over a year, this becomes a reconciliation line that nobody wants to explain.
Where the Debt Compounds
The compounding happens because the mismatch is never fully cleared. Consider a mid-sized employer with 4,000 employees contributing monthly:
- Month 1: Payroll file arrives 2 hours after cutoff. Allocated at T+1 NAV. Market moved +0.4% overnight. Participants collectively "lose" the equivalent of that 0.4% on a fresh contribution batch.
- Month 2: File arrives on time, but 180 records fail validation and are held. They clear three days later at a different NAV. Now there are two allocation dates for one payroll cycle.
- Month 3: State subsidy (devlet katkısı) is calculated on the original contribution date, but units were allocated on a later date. The subsidy allocation date and the contribution allocation date no longer match.
By month six, the operations team is running manual adjustment scripts. By month twelve, there is a suspense account that nobody wants to close because closing it means picking a number and defending it.
What Nobody Documents
The things I have found undocumented at nearly every institution:
- The exact definition of "arrival time" used by the allocation engine
- The behavior when a single payroll file contains contributions for multiple pay periods
- The treatment of corrections and reversals against NAVs that have already been struck
- The reconciliation logic between the contribution ledger and the unit ledger when they diverge
- The tolerance threshold above which a manual review is triggered — and who owns that threshold
Every one of these is a policy decision. Every one of them is currently a line of code written by someone who left three years ago.
The Fix Is Not Technical
Engineers reach for technical solutions: better SLA monitoring, tighter cutoff enforcement, automated retry logic. These help at the margins but they do not solve the underlying problem, which is that no one has formally decided what the allocation policy is.
The fix requires:
- A written contribution allocation policy signed off by finance, operations, and compliance — not IT
- An explicit definition of the timestamp that governs allocation, with the specific system of record named
- A documented handling procedure for late arrivals, failed validations, and multi-period files
- A reconciliation cadence that matches the risk, not the calendar convenience
- A suspense account policy that defines the maximum age of an unallocated contribution
Once those exist, the technical implementation becomes straightforward. Without them, every code change is just re-encoding somebody's guess.
The Auditor Question
The test I use with clients is simple. I ask them to pick a random contribution from six months ago and walk me through:
- When it arrived
- Which NAV it was allocated against
- Why that NAV was the correct one under written policy
- How the state subsidy allocation date was determined
- Where the reconciliation between the contribution ledger and unit ledger sits
If any of those answers requires a phone call to a specific person, the pipeline has a reconciliation debt. It may not have surfaced yet. It will.
The institutions that handle this well are not the ones with the best technology. They are the ones that treated the payroll-to-NAV bridge as a policy problem first and an engineering problem second. Everyone else is running on assumptions written into SQL by someone who is no longer there to defend them.