Every private pension (BES) pipeline I've built or inherited in the last decade has the same architectural sin: the access control layer was designed once, against the org chart in place at build time, and then quietly diverged from reality for the next five years. Nobody logs the divergence. Nobody re-attests it. And when the pipeline feeds three regulatory streams simultaneously — EGM, FATCA, and CRS — the divergence stops being an IT hygiene issue and becomes a signed-submission problem.
This is the delegated authority problem. And it is, without exception, an audit finding waiting to happen.
The Build-Time Snapshot Fallacy
When a BES pipeline goes into production, someone writes an access matrix. It usually looks reasonable on day one:
- Pipeline owner: senior data engineer, full prod access
- Batch operator: ops team lead, execute rights on the scheduled DAG
- Reconciliation reviewer: finance controller, read on staging + gold
- Regulatory signatory: compliance officer, read on the submission extract
Then day 400 arrives. The senior data engineer moved to the fraud team but kept their AD group. The ops team lead's role was split into two, neither of which formally inherited the execute right — but both people still have it because the group membership was never cleaned. The finance controller retired; her successor was added to a broader "finance-all" group that happens to include the same access plus write on three other systems. Compliance restructured and the FATCA sign-off moved from one officer to another, but the old officer's account is still active because he's still handling CRS.
None of this is malicious. None of it triggers an alert. And none of it appears in the pipeline documentation, which still reflects day one.
Why EGM, FATCA, and CRS Make This Worse
A pipeline that only fed EGM would already have this problem. What makes the BES case genuinely dangerous is that the same underlying participant and contribution tables feed three regulators with three different scopes:
- EGM cares about the domestic participant view, contribution history, state matching subsidy calculations.
- FATCA cares about US person indicia, and specifically about who can modify indicia flags.
- CRS cares about tax residency determination and reportable account status across jurisdictions.
One dataset. Three signatories. Three different definitions of "authorized to touch this record." And in practice, one AD group that grants write on the participant table to anyone who was ever on the BES ops rotation.
When the FATCA submission goes out and the auditor later finds that the US indicia flag on a specific account was updated by a batch run on a Tuesday in March, the question is not "was the pipeline correct." The question is: who ran that batch, under whose authority, and did that authority legitimately extend to modifying FATCA-relevant fields on that date?
I have never seen a BES pipeline that can answer that question cleanly without a week of forensic work.
The Segregation That Never Happened
Segregation of duties in BES pipelines usually exists on paper as a matrix between roles. But roles are not the enforcement layer — group memberships are. And group memberships get granted for reasons that have nothing to do with the SoD matrix:
- Someone needed to debug a production incident at 2am and was added "temporarily."
- A junior was shadowing and was given read to speed onboarding.
- A vendor consultant needed access for a migration project that ended eighteen months ago.
- The BI team needed a service account to pull reconciliation extracts, and the service account was given the same rights as a human operator because nobody wanted to design a narrower role.
Each of these is a defensible decision in isolation. Together they mean that on the day of the discrepancy, twelve people and four service accounts could have run the batch, and the pipeline logs will tell you which account executed it but not which human was behind that account.
What the Audit Actually Asks
When the finding lands, the auditor does not ask about your CI/CD pipeline or your dbt tests. They ask:
- Who was authorized to modify data feeding the March 15 FATCA submission?
- Show me the access review that confirmed this list on or before March 15.
- Show me the log evidence that only those people (or their authorized service accounts) touched the relevant tables between the previous submission and March 15.
- Show me the change control for any access grants made during that window.
If your answer to (2) is the annual access recertification that happened six months ago against an org chart that has since changed, you have a finding. If your answer to (3) requires joining AD logs against pipeline execution logs against ticket system approvals in a spreadsheet you build ad hoc, you have a finding. If your answer to (4) is "we didn't grant any" but the AD audit log shows three group membership changes, you have a finding.
What Actually Works
After enough of these cycles, a few things earn their keep:
- Bind access to the submission, not to the pipeline. Every regulatory extract should have its own access lineage, re-attested before each submission cycle, not annually. The FATCA extract's authorized modifiers list is a compliance artifact, not an IT artifact.
- Service accounts must have named human owners with expiry dates. No perpetual service accounts. If the owner changes roles, the account is frozen until re-owned.
- Log the human, not just the account. If a batch runs under a service account, the trigger (whether scheduled, manual, or API) must carry the human identity through to the pipeline log. Otherwise your forensic answer is always "the service account did it."
- Treat group membership changes on regulatory-relevant groups as change control events. They should generate a ticket, require approval, and be visible in the same change log as code deployments.
- Reconcile the SoD matrix against actual group membership monthly. Not annually. The drift between month one and month twelve is where every finding lives.
None of this is technically hard. It is organizationally hard, because it requires compliance, IT, and the data team to agree that access is a submission-scoped concern, not an infrastructure concern.
The Uncomfortable Part
The reason this problem persists is that nobody owns it until the auditor arrives. The data team owns the pipeline. IT owns AD. Compliance owns the submission. Access sits in the seam between all three, and seams are where audit findings breed.
If you own a BES pipeline today and you cannot, within thirty minutes, produce a signed list of who was authorized to modify FATCA-relevant fields on any given date in the last twelve months, the finding is already written. The auditor just hasn't visited yet.