Product view · IRSIllustrative
105KIRS trades (21% of total)
14variants
7%risk–valuation iteration
4h 18mmedian cycle time
Isolates a selected product population and reveals its observed paths, variants, cycle time and rework.
Use case · Capital marketsIllustrative
Trade Execution Intelligence.Connect business execution to technology reality.
Capital Markets operations run across many systems and handoffs. RE‑ViVE connects the dots—across Product, Execution, Systems and Technology—so a bank can see how 500,000 trades actually executed and act on what matters. The result is an execution-aware operational ontology: trades, products, activities, systems and technology components connected by how work actually occurred—not only by how those relationships were designed.
01The opportunity
Capital Markets execution is visible in pieces.
Banks already have deep visibility into trades, risk, applications, infrastructure and operational performance. The challenge is that these views are usually separated.
That separation makes it difficult to see how business execution and technology execution come together around the same trade population. A trade may pass through different capabilities depending on product, desk, counterparty, controls and exceptions. Supporting systems and technical processes may also operate at different frequencies.
The missing view is the connected execution context: what path actually occurred, which systems participated, and where time, rework and technology consumption accumulated.
Typical pathIteration / reworkCapability touchedThe product paths are illustrative. They do not impose one universal Capital Markets workflow; actual lifecycle activities vary by product and institution.
02How RE-ViVE approaches it
The Trade ID becomes the execution spine of the ontology.
RE-ViVE starts with a defined trade lifecycle and uses the Trade ID—or another deterministic business reference—to connect the operational entities involved in its execution: products, activities, systems, jobs, APIs and available technology evidence.
The objective is not to force every product into one standard path, but to reconstruct the path that actually occurred for each trade.
Different applications, jobs and services may run at different frequencies and may process different trade populations. They do not need to behave as one synchronized technical workflow. Where the Trade ID, or another deterministic reference that can reliably connect records across the scoped lifecycle, is available through technical execution, measurable technology consumption can also be associated with the relevant trades and paths.
Where deterministic Trade-ID lineage exists, technical execution and measurable technology consumption can be associated with the trades and paths that generated it.
Scope principle. RE-ViVE does not manufacture missing lineage. Where Trade-ID or other deterministic linkage cannot be established, that component stays outside attributed coverage; the analysis proceeds with the portion of the lifecycle that can be connected reliably.
- Representative source categories
- OMS / EMS and trading venuesOrder and execution management, exchanges and electronic venues
- Trade capture and reference dataTrade-capture platforms and reference-data services
- Risk, valuation and controlsRisk and valuation engines, limit and control checks
- Confirmation, matching and post-tradeConfirmation and matching services, product-dependent clearing and settlement platforms, reporting
- Messaging, scheduling and observabilityMiddleware, schedulers, job and API telemetry, observability platforms
- Cloud and on-premises infrastructureCompute, data movement and duration measures where lineage allows
Ontology Accelerator
From enterprise entities to observed execution relationships.
RE-ViVE does not replace an enterprise ontology. It adds execution evidence: which entities actually participated together, in what sequence, for which trades and with what observed outcomes.
03The execution model
500,000 trades. One observed execution model.
Individual Trade-ID histories become useful at scale when they are organized into a population-level execution model.
RE-ViVE automatically reconstructs the observed execution from the data itself—preserving paths, sequences, iterations, handoffs, exceptions and system participation across the 500,000-trade population. The bank does not need to define the paths or tell RE-ViVE how trades are expected to flow. Once the relevant Trade-ID-linked source records and execution evidence are available, RE-ViVE maps how the trades executed across the participating sources.
The two views below use the same underlying trade population. The metrics summarize the selected population; the process map is the execution evidence behind those metrics.
Execution view · high-complexity variantIllustrative
18%of trades
6.2haverage cycle time
2.1×vs straight-through
28%rework rate
Isolates a particular execution behavior or complexity pattern and shows how that population moved through the lifecycle.
Individual trade execution provides the evidence. The population-level execution model provides the context. The same model can be examined through System and Technology views for platform participation, dependencies and—where deterministic technical lineage is available—associated technology execution.
04What becomes visible
One execution-aware ontology. Four ways to examine it.
Once the population-level execution model is established, the same connected entities and 500,000 trades can be explored through four complementary views. These are not four separate analyses; they are different ways of interrogating the same observed execution evidence.
Which products, desks or counterparties exhibit greater complexity, variability, rework or cycle time?
Start from the business unit of account. Compare product families, desks and counterparties on the same execution measures, then drill into the population behind any difference.
- Execution complexity
- Variant frequency
- Rework concentration
- Cycle-time differences
- Technology consumption by product
Which paths, loops, exceptions, waits, handoffs and re-entry patterns actually occur?
Isolate a behaviour rather than a product: the straight-through population, the multi-handoff variant, the trades that iterated between risk and valuation.
- Dominant paths
- Rework and iteration
- Handoffs and waits
- Exceptions
- Cycle-time distribution
Which platforms participate in particular products and execution variants, and where are dependencies concentrated?
Observed participation rather than the application inventory: which platforms a product actually touches, how often they appear inside complex or rework-heavy patterns.
- Product dependency
- Path participation
- System touchpoints
- Handoff concentration
- Failure and exception association
Where do measurable technical executions, data movement, compute and other available technology measures accumulate?
Where deterministic Trade-ID lineage exists, technical runs and consumption evidence are associated with the paths that generated them.
- Compute consumption
- Data movement
- Integration activity
- Consumption by path
- Consumption by product
All four lenses read the same 500,000-trade execution model. Product and Execution reveal how trades execute; System and Technology reveal what supported them.
05The value
Questions that become answerable.
Because every question below is answered from the same observed trade population, an investigation can move from a business symptom to the underlying execution path, participating systems and available technology evidence without changing analytical foundations.
Execution
- Which products generate the most execution complexity?
- Where do trades repeatedly revisit Risk or Valuation?
- Where are repairs, resubmissions and reprocessing concentrated?
- Which counterparties, desks or products follow unusual paths?
Technology
- Which systems actually participate in each trade path?
- Which variants are associated with disproportionate technology consumption?
- Where does measurable data movement or technical execution accumulate?
- What additional technology demand is associated with rework?
Architecture & Transformation
- Which systems have the greatest observed business dependency?
- What trade populations and paths would be affected by changing a platform?
- Did modernization reduce rework, variability and technology consumption?
- Where should engineering investment focus first?
- Which relationships exist in architecture or ontology models but are rarely or never observed in execution?
Every question is answered from the same observed trade population.
06Illustrative output
A small trade population can drive disproportionate execution.
The execution model makes it possible to compare the share of trades following a particular variant with the execution activity and technology measures associated with that same variant.
In this illustrative example, a specific IRS execution path involving iterative Risk ↔ Valuation interactions occurs in a small subset of trades but generates disproportionate execution. Trade share is measured against the applicable product population; execution and technology measures are calculated from the corresponding observed events and attributed technical evidence.
500,000Total trades30-day period
105,000IRS trades21% of total
7,350Trades on the iterative Risk ↔ Valuation path7% of IRS trades · 1.47% of all trades
Disproportionate execution impactIllustrative
7%of IRS trades
Trades following this path represent 7% of all IRS trades.
21%of IRS valuation executions
These trades account for 21% of all valuation executions within IRS.
18%of measured technology consumption (IRS)
A disproportionate share of measured technology consumption associated with IRS execution.
2.4×cycle time vs the predominant IRS path
These trades take 2.4 times longer on average.
+3additional system interactions vs the predominant path
More handoffs and system touch points on average.
The purpose is not to infer causation from a percentage. It is to identify where execution is concentrated enough to warrant investigation.
Illustrative results demonstrate the analytical model. Actual findings are derived from client execution data.
07A CIO view
System dependency through actual execution.
Architecture and ontology models describe known or intended relationships. Observed Trade-ID execution adds another perspective: where a platform actually participates, which products touch it, and how frequently it appears within particular execution patterns.
System dependency · the EMS platformA core trading and execution platform, embedded in the most complex and time-consuming patterns.Illustrative
325,000trades touched the platform65% of the 500,000-trade population
5product families impactedEvery family in scope
42%of complex paths include the platformAmong trades following multi-step paths with multiple handoffs and system interactions
38%of rework / iteration paths include the platformAmong trades that experienced rework loops or iterations
Participation by trade volume
65% touched the platform · 325,000 trades
35% other platforms · 175,000 trades
Straight-through variant
Simple execution with limited handoffsCapture→EMS→Risk check→Confirmation
58%of straight-through trades include the platform · 190,000 trades
Multi-handoff / complex variant
Multiple systems and decision pointsCapture→EMS→Risk check→Valuation→Confirmation
70%of complex-variant trades include the platform · 21,000 trades
Rework / iteration variant
Loops and reprocessing before completionCapture→EMS→Risk⇆Valuation→Confirmation
74%of rework / iteration trades include the platform · 39,000 trades
"Trades touched" are trades in the population with observed participation by the platform. Percentages describe association with the observed populations; they do not by themselves establish that the platform caused the behaviour, and imply no exclusivity or performance attribution.
System criticality can be evaluated through observed business execution—not application inventory alone.
08Execution Intelligence + AI
Give enterprise AI an execution-aware ontology.
Enterprise AI can understand products, trades, systems and technology as related entities. RE-ViVE adds another dimension: how those entities actually participated in execution.
This gives AI grounded operational context for investigating exceptions, explaining execution patterns, assessing dependencies and evaluating change. The bank can apply this pattern with RE-ViVE's AI capabilities or, where appropriate, with its broader enterprise AI environment. RE-ViVE's deterministic execution model remains the evidence layer; AI helps users interrogate and interpret it.
RE-ViVE adds observed execution to the ontology. AI can reason over that grounded operational context.
Illustrative questions
- Why did IRS cycle time increase during this period?
- Which execution variants account for most Risk–Valuation iteration?
- Which systems participate most frequently in those variants?
- How does their observed technology consumption compare with straight-through execution?
09From pilot to decision
Start with one meaningful trade lifecycle.
The objective is not to map the entire Capital Markets technology estate. Start with a defined trade population, connect the evidence that can be linked reliably, and use that model to answer practical operational and technology questions.
With usable source data available, the first execution view can typically be established in approximately 10 business days. A focused pilot should prove that the bank can provide a deterministic scope, RE-ViVE can reconstruct the observed execution, and the resulting evidence can support decisions.
A practical pilot · shared responsibilitiesFive stages, three lanes.
| Pilot stage | What the bank provides | What RE-ViVE does | What this enables |
|---|---|---|---|
| 1Choose the scope | Select a meaningful product or trade lifecycle, observation period and trade population. Identify SMEs for validation. | Confirm scope, minimum evidence and the initial analytical questions. | A bounded use case tied to decisions the bank cares about. |
| 2Provide the evidence | Read-only access, approved extracts or equivalent access to principal business systems. Include job, API and telemetry evidence where technology attribution is desired. | Profile the evidence, identify usable Trade-ID or deterministic references and load the required data. | Evidence without production application or workflow changes. |
| 3Validate the lineage | Validate identifiers, lifecycle meaning, source relationships and known gaps. Confirm where deterministic linkage is available. | Connect Trade IDs, or other deterministic references, across the material business events and technical runs that can be linked reliably. Keep unsupported components outside attributed coverage. | A defensible execution spine based on observed evidence. |
| 4Build the model | Review representative paths and exceptions and confirm the observed behaviour is operationally meaningful. | Reconstruct actual paths, variants, loops, handoffs, rework and system participation. | One population viewed through Product, Execution, System and Technology. |
| 5Turn evidence into decisions | Bring the operational, architecture and technology questions to investigate and validate findings in business context. | Analyze concentration, dependencies, rework, cycle-time patterns and available technology measures. | Evidence for rework reduction, modernization, technology optimization and measuring change. |
See execution
Reveal actual paths, variants, loops, handoffs and rework across the scoped trade population.
Understand dependency
See which systems participate in products and execution patterns before modernization or platform decisions.
Connect technology
Where deterministic lineage exists, associate available technical execution and consumption evidence with the paths it supports.
Measure & act
Establish a baseline for cycle time, rework, variability and system participation that can be compared after change.
Move from a defined trade population to an observed execution model—and from that model to decisions about operations, systems and technology.
10The end state
From fragmented evidence to Trade Execution Intelligence.
A continuously usable execution view that connects business activity with the systems and technology supporting it. Move from a product question to an execution path, from that path to system dependency, and from system participation to available technology evidence—without rebuilding the analysis each time.
One connected execution ontology
Product
- Complexity by product
- Cycle-time differences
- Desk and counterparty context
Execution
- Actual paths and variants
- Loops, waits and rework
- Exceptions and re-entry
Systems
- Observed participation
- Dependencies and handoffs
- Concentration in variants
Technology
- Consumption by path
- Jobs, APIs and data movement
- Available compute and duration measures
Understand not only what was traded—but how the enterprise actually executed it.
Continue reading
The discipline behind the use case.
Start with one trade lifecycle or bring your Ontology use case.
Choose the product or trade population whose execution is least understood, or tell us about the ontology you are trying to build. We will tell you, before any commitment, whether the data you already hold can reconstruct it.