Publication matrices belong in code, not spreadsheets

Somewhere in every fund data operation, there's a spreadsheet called something like "Dissemination Matrix v14 FINAL (2) - Copy.xlsx". It controls which data goes where. It is always wrong.

I've maintained these spreadsheets. Rows are funds or share classes. Columns are destinations — Bloomberg, SIX, Morningstar, the website, the client portal, the regulatory feed. Cells contain "Y" or "N" or sometimes "Y but only after board approval" in a comment that nobody reads.

Every month, someone adds a fund and forgets to update the matrix. Every quarter, a new destination appears and someone adds a column. Every year, someone accidentally deletes a row and a fund stops publishing to three platforms. Nobody notices for two weeks.

What a publication matrix actually is

Strip away the spreadsheet, and a publication matrix is a set of rules:

• Which entities (funds, share classes, by filter criteria)
• Which fields (NAV, performance, static data, specific Openfunds fields)
• To which destination (SFTP endpoint, API, file drop)
• In which format (CSV with these columns, XML with this schema, JSON to this API)
• On which schedule (daily at 18:00 UTC, monthly on T+1, on-demand)
• With which conditions (only after validation passes, only if NAV has changed)

That's not a spreadsheet. That's a configuration object. And configuration objects belong in code, where they can be versioned, tested, reviewed, and deployed.

The data model

We model outbound delivery as pipes. Each pipe is a declarative configuration:

A pipe has a source_filter (which entities), a field_set (which data points), a transform (output format and field mapping), a destination (where it goes), and a schedule (when it runs). Each pipe also has a gate — conditions that must be true before delivery proceeds.

The gate is crucial. In spreadsheet world, someone manually checks that NAVs are validated before publishing. In code, the gate is explicit: quality_score >= 0.95 AND validation_status = 'passed'. If the gate fails, the pipe doesn't fire. No human required.

Why this matters operationally

Three scenarios that break spreadsheet-based matrices every time:

Fund launch. New fund, 12 share classes, needs to publish to 8 destinations. In spreadsheet world, that's 96 cells to fill in correctly. Miss one, and the Zurich office calls asking why the Swiss-registered class isn't on SIX. With pipes, you define the fund's publication profile once. The pipes pick it up by filter criteria.

Destination change. Bloomberg changes their upload format. In spreadsheet world, you update the process documentation (ha), hope the operations team reads it, and pray. With pipes, you update the transform on the Bloomberg pipe. It's a code change. It goes through review. It has a test.

Audit. The regulator asks: "When did you start publishing Fund X to Platform Y?" In spreadsheet world, you dig through email chains and SharePoint version history. With pipes, you check the git log. Exact timestamp, exact change, exact author.

If you can't answer "who changed the delivery configuration and when" in under 30 seconds, your publication matrix is a liability.

The reconciliation layer

Pipes also solve the "did it actually arrive?" problem. Each pipe execution produces a delivery receipt: what was sent, when, to where, and a hash of the payload. You can reconcile outbound deliveries against destination confirmations.

We track delivery status per pipe per execution: pending, delivered, confirmed, failed. A dashboard shows which pipes fired today, which succeeded, which are stuck. This replaces the morning email chain of "did the Bloomberg file go out?"

Yes, it did. At 18:03 UTC. Here's the receipt. Here's what was in it. Here's the confirmation. Move on.

Getting there from here

If you're currently running on spreadsheets — and statistically, you are — the migration path is straightforward. Export your matrix. Each row-column combination with a "Y" becomes a pipe definition. Codify the implicit rules that live in people's heads. Deploy. Delete the spreadsheet.

The hardest part isn't the technology. It's convincing the team that the spreadsheet they've maintained for six years is the problem, not the solution.

Publication matrices are infrastructure. They determine what the outside world sees. Infrastructure belongs in version-controlled, testable, auditable code. Not in a spreadsheet with 14 versions and a prayer.