Straight-Through Processing Is Not an API Feature
Two systems can be connected and still leave your firm re-keying, reconciling and owning the gap. Integration is a question of operating model, not connectors.
Two systems can be connected and still leave your firm re-keying, reconciling and owning the gap. Integration is a question of operating model, not connectors.
The vendor confirmed the two systems have an API. Everyone relaxed. Nobody asked where the data is authored, who validates it, or who owns it when it lands in the second system — which is where straight-through processing is actually won or lost.
When a firm wants two systems to work together — a CRM and a custody platform, an onboarding tool and a downstream book of record — the conversation almost always collapses into a single question: is there an API? If the answer is yes, the integration is treated as solved. But the existence of a connector settles almost nothing that matters. Straight-through processing is not a property of the pipe between two systems. It is a decision about where data is authored, where it is validated, where it is transformed, and who owns it at each step.
Get that decision right and an API is one useful implementation option among several. Get it wrong and the best API in the world simply moves your unresolved operating-model problem from one system into another, faster. This matters acutely in Jersey, where the typical firm does not own a single monolithic system but stitches together a CRM, a custody or platform provider, an administrator and a book of record — often from four different vendors. Every seam between them is one of these decisions waiting to be made, and the more outsourced the stack, the more seams there are to get wrong.
The API question is the last question, not the first
A well-run integration decision does not start with the connector. It starts with the operating model, and works through a sequence of questions that the word integration usually skips. Should this data be re-keyed by a person, or should it flow automatically? Does a connector already exist, and does it move the right data or merely some data? Is a direct platform-to-platform integration appropriate, or is a scripted transformation layer — one the firm controls — a better fit? What will the destination system actually require, and is that requirement even known yet?
The pattern I return to is that firms treat these as technical details to be resolved after the decision to integrate, when they are in fact the decision. The most consequential of them is often the last: what does the destination require, and do we know? A great many integration problems are not connector problems at all. They are the consequence of designing the first system's data flow before anyone understood what the second system would need — so the data arrives in a shape the destination cannot use, and a human quietly re-keys it anyway.
Integration is not a connection between two systems. It is a decision about where work happens — and connectors are how you implement that decision, not how you make it.
Four questions that decide the operating model
Every genuine integration decision resolves four questions, and each is an operating-model question rather than a technical one. Where is the data authored — which system is the point of entry and the system of record? Where is it validated — which control point checks it before it flows on? Where is it transformed — does the firm or the vendor own the mapping between one system's shape and the next? And who owns it downstream — who is accountable for the data once it lands in the second system? None of these is answered by a connector. An API can move data from A to B, but it cannot decide whether A or B is the system of record, where validation should sit, who owns the transformation, or who is accountable when the data arrives. Those are choices the firm makes — or fails to make, in which case they are made by default, usually in whatever way is easiest for the vendor rather than best for the firm.
The value of writing the four questions down is that they become a worksheet you complete once per data flow, before any connector is chosen — and a flow with a blank cell is a flow with an unmade decision. Table 1 is that worksheet, with a worked line showing what a completed row looks like; copy it, and fill one row for every integration in your target operating model.
Table 1 — The straight-through processing worksheet: complete one row per data flow before choosing a connector
| Decision to record | What must be named in the cell | Worked example: client data, CRM to custody |
|---|---|---|
| System of record | The one system that authors this data; all others read it. | CRM authors client and entity data; custody consumes it. |
| Validation point | Where and by whom the data is checked before it flows. | Validated in CRM at onboarding; no re-check downstream. |
| Transformation owner | Who owns the mapping between the two systems' shapes. | Firm-owned transformation layer, not the vendor's importer. |
| Downstream owner | The named role accountable once the data lands. | Operations lead owns the custody-side record and any breaks. |
| Chosen mechanism | Re-key, direct integration, or scripted layer — and why. | Scripted layer: control retained, volume too high to re-key. |
Re-keying is a design decision hiding as a default
The clearest symptom of an unmade operating-model decision is re-keying: a person retyping data that already exists in another system. It is almost never chosen deliberately. It appears because the flow between two systems was never fully designed, so the gap gets filled by the most flexible resource available — a human. Every instance of re-keying is a place where the firm decided, without deciding, that a person would absorb the cost of an integration that was never finished.
The right way to weigh the options is against the target operating model, control ownership and duplication risk — not against connector availability. Manual re-keying, a direct integration, and a firm-controlled scripted transformation layer each have a legitimate place; the question is which one fits the control model the firm wants, at a cost the firm can justify. Sometimes a controlled manual step with a clear owner is genuinely the right answer for a low-volume, high-judgement flow. What is never right is drifting into re-keying because nobody made the call.
There is a regulatory reason to make these choices deliberately rather than by default. The JFSC guidance asks firms to maintain data quality — validating inputs and keeping records sufficient for audit and challenge — and undesigned re-keying works directly against both. Every manual retype is an unlogged point where an error can enter, and a place where the audit trail depends on someone remembering what they typed and why. A firm that can point to a designed flow, with a named system of record and a defined validation point, can evidence its data quality. A firm running on quiet re-keying cannot — it can only hope.
Agentic AI raises the stakes on every one of these questions
This is not a legacy-integration concern that AI makes obsolete. It is a concern that agentic AI makes sharper, because autonomous workflows require the four questions to be answered explicitly rather than left to a human to paper over. When a person sits between two systems, they silently absorb every gap in the design — they notice the mismatched field, the missing validation, the ambiguous ownership, and they fix it without anyone recording that a fix was needed. An agent does not. It acts on the rules it was given.
So an agentic straight-through process forces the firm to state, in advance and in code, what the human was doing implicitly: which system is the source of record, what validation must pass before an action is taken, how data is transformed between systems, and where the hand-offs sit. Jersey's guidance already treats agentic AI — systems that act without real-time human approval — as warranting the strongest controls for exactly this reason. Straight-through processing was always an operating-model decision. Agentic AI simply removes the human who used to hide the fact that the decision had not been made.
Where two of your systems are connected, can you say — without checking — which one is the system of record, where the data is validated, and who owns it downstream? Or is a person quietly re-keying across the gap you never designed?
Next: why a data migration is really an audit of how the firm operates — A Migration Project Is an Operating-Model Audit in Disguise.
Sources: JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 1 (agentic AI controls, human oversight) and Principle 2 (data quality, auditability); AI Strategy in Jersey FS, Series 2 Part 5 (agentic AI).
Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.
Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator
See where your firm stands
The free diagnostic scores your firm across the twelve operating-model instruments in about eight minutes.
Take the diagnostic →A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.
The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com