Why operating architecture matters as much as market access

A new market connection can look like progress: another data feed, another venue, another dashboard. But a connection does not explain who may act on the information, which assumptions have been reviewed, or what happens when the expected result does not arrive. For teams exploring digital assets, operating architecture is the design of those relationships. It connects an observation to a decision, a decision to an accountable owner, and an action to a record that another person can understand.

Start with a clearly bounded workflow

Choose one recurring activity, such as preparing a market research briefing or evaluating a technology provider. Write down the trigger, the intended output and the people who depend on it. Avoid starting with an organization chart: a workflow often crosses several responsibilities, while a chart tells you little about what information changes hands.

For a research briefing, the sequence might be collection, validation, interpretation, review and publication. Each step should have an owner, an expected input and a clear definition of completion. The reviewer needs to know which claims are supported, which are estimates and which questions remain open. The publisher needs a confirmed version and an explicit release decision. These are different responsibilities even when a small team assigns several of them to one person.

Separate access from authority

Being able to open a system is not the same as being authorized to approve a business action. A practical process should distinguish who can view information, who can prepare a change, who can approve it and who can execute it. Where staffing prevents complete separation, identify that constraint and arrange a documented second review for consequential decisions.

Established frameworks offer useful questions. The CPMI-IOSCO Principles for Financial Market Infrastructures address governance and operational risk for defined types of financial market infrastructure. Their scope should not be confused with a general startup checklist or a certification. Our interpretation for an early design exercise is narrower: ask whether responsibility is clear and whether the process can cope with a plausible disruption. Referencing the principles does not establish that Arclight is an FMI or complies with them.

Document the handoff, not just the task

A handoff should carry enough information for a colleague to continue without reconstructing the entire discussion. Include the purpose, current status, source material, important assumptions, outstanding questions and next owner. Make the difference between “prepared,” “reviewed” and “approved” visible. A single label such as “done” can hide an unresolved dependency.

Consider a provider evaluation. A technical connection may work while pricing terms, access restrictions or data retention arrangements remain undecided. The evaluation record should make those gaps visible rather than allowing a successful demonstration to stand in for an overall approval. This is a proposed review method, not a statement about any provider relationship currently held by Arclight.

Design the exception path early

Normal steps are relatively easy to diagram. The more useful exercise is to ask what happens when a source is unavailable, two records conflict or the designated reviewer is absent. Name the conditions that pause the workflow, the person who can resolve them and the evidence required to resume. Do not allow an exception to become an undocumented permanent workaround.

NIST's Cybersecurity Framework 2.0 includes governance alongside identification, protection, detection, response and recovery. It provides context for discussing risk across an organization. In our proposed workflow, that translates into a simple question at each handoff: who accepts the remaining uncertainty, and where is that decision recorded?

Test the design with a small exercise

Walk through one realistic scenario with the people who would handle it. For example, introduce a conflicting market observation immediately before a research note is due. Can the team identify the affected claim, locate its source, contact the reviewer and decide whether to delay publication? Record where the process depended on memory or on one unavailable individual.

Use the findings to improve the next version. Useful measures include unresolved exceptions, repeated rework and the time needed to reconstruct a decision. Speed matters, but a fast process that cannot explain its output is difficult to review. A modest workflow with clear ownership is a better starting point than a large collection of tools whose responsibilities remain ambiguous.