Fictional MS-62: a missing order event and an unresolved participant relationship limit different conclusions. The review packet is proposed and untested.
Engineering guide · Sources reviewed 26 October 2026
Choose market surveillance evidence by the question an analyst must resolve. A cancellation ratio can identify activity worth reviewing, but it cannot explain the complete order history, the surrounding market or the relationship between participants. The review packet needs enough retained context to support a reasoned finding and identify where the evidence stops.
For a CASP, that means joining original market events to the detector that selected them and the analyst who interpreted them. The fictional alert MS-62 below illustrates the selection process. Its identifiers and circumstances are invented. No customer activity, manipulation finding or surveillance acceptance test was performed for this article.
A missing link between matching-engine records and case review is an engineering problem. Pharos Production's published market surveillance software development scope covers order-book and trade surveillance, analyst case management and an audit trail. That makes the evidence interface a relevant delivery discussion. The published scope does not establish a result for this fictional alert or a measured detection improvement.
Write the behavior being investigated as a question that the evidence could answer. For an order-placement pattern, the question might concern whether visible liquidity was repeatedly withdrawn around opposite-side executions. That differs from asking whether two accounts share control, whether a detector used the intended configuration or whether the available feed is complete. Give each question its own possible finding. An analyst may establish that a sequence occurred while leaving the participant relationship unresolved. A data-quality defect may prevent reconstruction without explaining the participant's purpose. Keeping these findings separate prevents a compelling chart from carrying a conclusion that its underlying records cannot support.
State the instrument and venue scope, the review interval and the evidence cutoff. Identify why that interval was selected and what surrounding context the analyst will inspect. A detector's event window can be a useful starting point, but it should not silently become the entire investigation boundary. Preserve later scope changes so another reviewer can understand why the selected records expanded or contracted.
For each review question, mark which records are required to support the intended finding and which are conditional on a particular hypothesis. Original lifecycle events may be required for a claim about order behavior. Communications or cross-venue records may become relevant when the question concerns coordination or activity outside the initial venue. Record why they are needed instead of collecting them by default. Give every selection a decision consequence. If a required source is unavailable, state which finding must remain limited or unresolved. If a conditional source is excluded, document the assumption under which that exclusion is acceptable. Additional low-value records should not conceal an absent source on which the conclusion actually depends.
Review that classification when the hypothesis changes. A packet selected to explain a detector threshold may be insufficient for attributing coordinated behavior. Keep the earlier scope and the reason for expanding it. This classification is an evidence-design decision for the stated task, not a declaration that the same fields are legally mandatory for every market or entity.
Assume MS-62 was generated by rule R-8 under configuration C-3 using input revision E-1. The candidate records include orders O-11 and O-12, an opposite-side fill F-9 and account mapping M-6. The source export contains a gap at sequence 812. The available mapping does not establish whether the relevant accounts share control. These are deliberately separate limitations in an invented example.
The analyst's initial job is to identify which observations remain supported despite those gaps. The fill record may establish a reported execution within its source boundary. It cannot supply the missing order event. Similarly, a repeated account label cannot establish a beneficial-owner relationship that M-6 does not document. Neither gap should disappear when the case interface groups the records together.
Use the selection matrix to connect each review question with the required record, join and inference limit. It is a proposed packet design, not a legal minimum or a tested vendor specification. If sequence 812 or a supported account relationship becomes available later, issue a new evidence revision and a linked assessment. Preserve what the earlier reviewer could actually see in E-1.
Select original order events that explain entry, acceptance, amendment and cancellation, together with executions and rejected instructions where relevant. Keep the distinction between a requested action and the venue's response. A cancellation request does not establish that a resting order was removed before another event occurred. The source acknowledgement and event sequence determine what can be reconstructed. Retain stable order identity across replacements and revisions. If an amendment produces a new venue identifier, preserve the correspondence and the field semantics. The review should show which price and quantity were effective at the event under examination. A current order snapshot can conceal an earlier state that mattered to the alert.
For MS-62, identify where sequence 812 falls within the declared source sequence. Explain which lifecycle transition becomes uncertain because it is missing. Do not infer the missing event solely from the order's final status. If the source uses sequence numbers for a broader stream, document that scope before claiming the gap belongs to O-11. The packet must distinguish an observed discontinuity from an established missing business action.
An alert is a derived result. Preserve the rule or model revision, its effective configuration and the input population used to produce it. Include the meaning of each displayed indicator and any filters or exclusions applied before evaluation. A screenshot showing a high score cannot explain whether the detector received the records the analyst now sees. Keep the generated alert separate from later enrichment. A corrected instrument mapping, a restored feed segment or a changed threshold can alter the review view without changing what originally triggered MS-62. Record the new evaluation as a new result with its own basis. Do not relabel the original alert with today's configuration merely because the rule name stayed the same.
Select enough material to explain the result at the agreed level. Inspection of retained inputs and configuration is different from rerunning the exact historical software. Where exact replay depends on unavailable models or services, state that boundary. The analyst should still be able to identify the original inputs, the recorded output and the interpretation that supported the review, subject to declared retrieval limits.
For an order-book hypothesis, preserve the relevant book state and event stream around the selected activity. Identify venue and instrument precisely, including the units and price conventions used. State whether the data represents displayed depth, aggregated levels or another source view. Those representations support different claims about liquidity and order interaction. Choose surrounding activity that can challenge the alert's interpretation. A market-wide repricing, a session transition or an instrument-specific event may change how a cancellation sequence should be read. Record the source and timing of that context. An unverified explanation supplied after the event should remain an analyst hypothesis until supporting material is available.
The packet need not mirror every market dataset. It should disclose what the selected context covers and what it excludes. If a claim concerns activity across venues, a single-venue chart cannot establish the complete relationship. Identify the additional source needed and whether it is available under the intended permissions. Broader visual coverage is useful only when its timestamps, instrument mappings and source limitations remain inspectable.
Retain the definitions behind every ratio shown in the case. Record the numerator and denominator, aggregation window and treatment of amendments or repeated messages. An order-to-trade measure can change when the system counts replaced orders differently, even if the underlying trading activity is unchanged. The analyst needs the definition used for this result.
If a review compares the activity with a baseline, identify the selected population and why it is relevant. The comparison might involve the same instrument in a different interval or a declared peer group. Do not treat a threshold inherited from another liquidity regime as a universal indicator of manipulation. Preserve the rationale and the configuration owner responsible for its use.
Explain units at the transformation boundary. Asset quantity, notional value and displayed depth are different measures. A converted amount needs its conversion basis and timing if the comparison depends on it. No alert threshold, risk score or historical percentage in a packet should acquire regulatory meaning solely because it appears beside a compliance workflow. MS-62 contains no measured ratio or production baseline.
Select the account and participant relationships needed for the actual question. Preserve the mapping source, effective interval and revision, together with the reason that a relationship was established. A shared routing endpoint or similar display name can identify a lead for investigation without establishing common control. Keep the distinction visible in the case record.
The UK Financial Conduct Authority's May 2021 Market Watch 67 discusses incorrect client-code mapping in order-book reporting and states:
This may limit our ability to undertake effective market abuse surveillance.
That warning concerns the FCA's UK-equity surveillance context. It illustrates why identity joins deserve source evidence; it does not import UK reporting requirements into a MiCA case or establish a relationship between the fictional accounts in MS-62.
For M-6, show which links are documented and which remain unresolved. If a later mapping changes the relationship, retain the earlier interpretation and explain the revision's effect on the finding. Limit access to underlying personal information according to the operator's authorized policy. A recipient may need a controlled relationship reference rather than a copy of every identity document.
Retain source event time and local receipt time where they answer different questions. Identify the clock source and any known synchronization limitation. A displayed chronological list should not imply a precise order between events whose timestamps overlap within the available uncertainty. Use supported source sequencing and causal relationships alongside time.
Choose a completeness check appropriate to each feed. Record source sequence coverage, retrieval boundaries and any replay or repair performed during collection. A missing number can indicate a discontinuity without identifying its business content. A successful export can also omit records when a filter, pagination failure or permission boundary narrows the returned population.
For MS-62, the source gap at 812 belongs in the review findings and the packet manifest. State whether the analyst can still answer a narrower question with the retained records. A restriction on one conclusion does not make every observation unusable. Conversely, an attractive visualization of the available events does not repair the absent event. Assign ownership of the gap and record what evidence would change the completeness assessment.
For each selected source, retain the collection boundary and provenance. Include the account or dataset scope, retrieval time and the transformation used to create the review view. Store the permitted original artifact with its normalized representation or a controlled retrieval reference. Distinguish an exact retained source from a summary reconstructed after access ended. A normalized event should identify which original record supplied its meaning. Preserve mapping revisions for renamed statuses and converted fields. If an event was excluded from a chart, the packet should explain why it was excluded and whether the analyst can inspect it. Otherwise, a presentation decision can become an unnoticed evidence-selection decision.
Content hashes can help detect changed retained bytes. They cannot establish that a source was accurate, that every relevant event was collected or that the analyst had the correct permissions. Keep those assurance questions separate. The packet should allow another reviewer to follow an observation back to its declared source boundary without mistaking a technical integrity check for proof of the behavioral hypothesis.
Include material that challenges the initial explanation. For a cancellation pattern, examine the source-supported reasons and surrounding activity that could explain withdrawal or repricing. Avoid adding a benign explanation as a conclusion simply because it is plausible. Record it as an alternative, identify the evidence needed and state whether that evidence is available.
Separate the analyst's observations from inferences. An order event may establish that a cancellation occurred after a reported fill within a known sequence. The participant's purpose is a different proposition. A relationship inferred from a partial sequence should not become a statement of intent in a summary or escalation merely because several indicators point in the same direction.
Record why an alternative was accepted, rejected or left unresolved. If the case is escalated despite an unresolved alternative, preserve that reasoning and the applicable review authority. Evidence selection should make the decision understandable to a second analyst. It should not turn the original alert into the only explanation the interface permits the reviewer to consider.
The disposition needs a specific scope and evidence version. Record which observations support it, which limitations matter and what remains open. Distinguish closing an alert under a documented rationale from establishing that no abuse occurred anywhere outside the reviewed scope. An unresolved data issue should retain its owner even when another case action is completed.
Preserve the reviewer identity and any actual required approval. A case being assigned to a senior analyst does not prove that a required review occurred. Keep the action record that shows what was approved, when and against which packet. A later correction should create a linked assessment rather than silently rewriting the earlier rationale.
The AML alert evidence model guide covers the adjacent problem of keeping original detection separate from later case knowledge. Market surveillance adds its own order and market-context requirements. Reuse the evidence-history discipline while preserving that distinction. The MS-62 packet must still explain its order-event gap and participant-mapping limit; an AML case template alone cannot supply either source.
MiCA Article 92, as reproduced by ESMA, addresses arrangements to prevent and detect market abuse and reporting of reasonable suspicion, including orders and their cancellation or modification. The legal assessment is not equivalent to passing a completeness checklist or proving a final misconduct finding. Applicable reporting timing must be handled by the responsible compliance function; obtaining a fuller packet is not an automatic reason to postpone that assessment.
ESMA's April 2025 supervisory-guidelines announcement concerns practices for national competent authorities. It highlights a risk-based approach and crypto-market features such as cross-border activity and social media. It is contextual supervisory material, not a universal field list for every analyst packet.
Have the responsible owner determine the actual notification obligation and required information for the relevant entity and jurisdiction. Preserve the assessment, evidence cutoff and any subsequent updates. This article proposes an engineering selection method. It does not assign a legal suspicion threshold to R-8, authorize a filing or replace the operator's applicable escalation procedure.
Select the level of detail that the intended recipient can inspect lawfully and meaningfully. The analyst may need event-level market records and a controlled account-relationship reference, while another recipient may receive a narrower explanation. Record what was withheld or redacted and how an authorized reviewer can obtain the underlying source when required. Test the retrieval route using the intended role. A link opening for an administrator does not establish that the analyst can access it. If the packet relies on a provider console, identify the required entitlement and what remains available when that access ends. The CASP evidence engineering hub provides the broader control-trace context for that handover.
Keep retention and access rules explicit for source material, derived indicators and case reasoning. Use the applicable policy rather than assuming that permanent copies are necessary for every review. A missing or expired source should be visible as a limitation with an owner. It must not appear as an unexplained empty field that a later reader mistakes for a negative finding.
Use synthetic data to evaluate whether the chosen packet supports the declared questions. Ask a second authorized reviewer to identify the order lifecycle, the effective detector basis and the limits of participant attribution. The proposed MS-62 exercise should expose the gap at 812 and the unresolved M-6 relationship as different findings. No such exercise was run for this article.
Change one condition at a time. Restore a source segment, alter a mapping revision or deny access to one retained artifact. Require the reviewer to identify which conclusion changes and which remains supported. Record the actual outcome if the exercise is later performed. An expected result in an acceptance document is not evidence that an implementation already meets it.
Keep historical inspection separate from exact replay. Where replay is offered, define the retained software and data dependencies and the supported output comparison. Where it is unavailable, require an honest statement of what can still be inspected. A packet that explains an original result can be useful without promising indefinite reproduction of a retired detector service.
A useful MS-62 packet does not establish that every alert receives equivalent evidence. Define the population and selection rule for a broader review. Include the statuses and source routes that could be missed by a list derived only from completed cases. Record whether the population covers all generated alerts or a justified sample and preserve its exclusions.
Compare the expected review inputs with what is actually available for that population. A missing detector revision or a recurring retrieval failure is an operational gap even if one demonstration packet looks complete. Measure those gaps from declared records before reporting completeness, review effort or any improvement. This article supplies no production coverage rate, false-positive reduction or analyst-time saving.
When an engineering gap prevents a reasoned review, Pharos Production's MiCA compliance software development service provides a relevant scoping route. Bring a synthetic alert and the recipient's unanswered question. Agree the source boundary, required joins and acceptance evidence before choosing an interface or estimating delivery. The deliverable should preserve why the analyst reached the finding and what the retained material could not establish.
Dmytro Nasyrov. Photo supplied by the author.
Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.