All insights

When the process becomes the product

As bespoke middle-office workflows become purchasable standards, the operating model shifts from designing processes to assembling components — and the value moves to the seams.

By Nick Ross6 min read
Editorial illustration for: When the process becomes the product

What it is

The middle office was always the part of the machine you could not buy. Front office systems had licences. Accounting systems had licences. The workflows in between, margin calls chased across counterparties, reconciliations built against whatever file arrived, share class conversions handled by whoever had done one before, were bespoke by default. They lived in spreadsheets, in cut-off calendars, and in the heads of a few people. The knowledge of how they worked was the firm's private property, and it was rarely drawn anywhere.

That is ending. In the space of four days this month, the last of those workflows started turning into products. The FIX Trading Community published a standardised messaging framework for margin requirement reporting between asset managers, clearing brokers and swap providers, a common, machine-readable language for margin information that has always travelled in bespoke files. Meeder Investment Management deployed FundGuard's cloud-native investment accounting platform, replacing a legacy accounting system outright. Thornburg handed SS&C the operational plumbing of its new ETF share classes, conversion processing included. And Gresham put multi-way reconciliation control design on the business desk, no code required.

Four different workflows, one event: a process that used to be private knowledge became a purchasable standard, maintained by someone else, with a contract and an SLA.

Why it matters now

Three things are converging.

First, the standards have finally arrived. Margin reporting is the telling one. It is one of the last inter-firm workflows with no common format, and the absence of a standard was the moat around a thousand bespoke processes. Standards convert the bespoke layer into a commodity, and the moat disappears with it.

Second, the economics of cloud-native platforms have crossed into the mid-tier. FundGuard at Meeder is the marker: a mid-size US manager running its own fund administration business now buys its accounting engine as a service rather than maintaining a legacy system. What the giant servicers adopted first is now the default ask of everyone else.

Third, the vendors are competing on taking the work, not just selling the tools. SS&C's ETF share class service includes conversion processing and shareholder coordination. Gresham's pitch is that the people who understand the data control the process. The transaction has changed shape: it is no longer "buy our software", it is "hand us the workflow".

For the operations team, the consequence is structural. When the bespoke workflows become products, the operating model shifts from designing processes to assembling components, and the discipline moves to the seams: what each component consumes, what it produces, who owns it when it fails, and where the exceptions land.

What firms should do

First, inventory the bespoke layer. List the workflows that are still private knowledge, and check each one against the catalogue now available. If a purchasable standard exists, running the bespoke version is a decision with a cost, not a fact of life.

Second, draw every bought component as a component: inputs, outputs, owners, failure modes. The firms that skip this step buy the standard and then bolt bespoke exceptions around it, which is the bespoke process with extra invoices attached.

Third, move people to the seams. When the process is a product, the value of the ops team concentrates where products meet: data mapping, exception ownership, escalation paths, the conversations no vendor can have with your counterparty. Teams still doing assembly work will find themselves doing it against bought standards, which is the least defensible place to be.

The opmodal perspective

This is where the Architecture Canvas earns its keep. A model drawn honestly shows each bought component at its boundaries: what feeds it, what it feeds, who owns the interface, what happens when it breaks. Firms whose model can show the boundaries can adopt each new standard as an upgrade to a known component. Firms whose model cannot will adopt the standard and inherit the mess around it.

The quiet weeks are when the operating model changes. No front pages, no conference keynotes, just a messaging standard, an accounting platform, a share class service and a reconciliation studio, each one removing a little more of the bespoke layer that defined the middle office for a generation. The firms that redraw the model as the components change will find the middle office finally frees its people for oversight, which is what the operational resilience rules have been asking for all along.

Keep reading

Process ownership: the discipline that keeps operating models alive

The business blueprint: one connected picture of how your organisation works