Five CASP Evidence Export Architectures Compared

By Dmytro Nasyrov · September 19, 2026 · Engineering architecture comparison

Scope: proposed export designs and a fictional validation fixture. No product benchmark, certification or legal opinion.

Choose a CASP evidence export architecture by testing what an independent recipient can establish after receiving the result. A snapshot can freeze a bounded population. An event export can preserve a decision sequence. A warehouse extract can support analysis across large populations. A signed bundle can bind the delivered files to an identified issuer. A federated query can assemble evidence from systems that remain under separate ownership. Each arrangement leaves different dependencies for the reviewer.

The selection turns on three questions: what is frozen, what the recipient can verify, and what remains dependent on a live service. Start with the recipient's actual request and reject any design that silently drops records, mixes incompatible cutoffs or conceals an unavailable source. The comparison below uses proposed engineering criteria and a fictional withdrawal case. It reports no product benchmark or customer deployment outcome.

Compare complete delivery arrangements

These five patterns are named for their dominant component, not presented as mutually exclusive technologies. A signed bundle can contain a snapshot, event history or warehouse result. A federated query can produce that bundle. The architecture is the complete path from approved request to independently interpretable delivery, including selection, freezing, packaging and verification.

This distinction prevents an attractive feature from answering the wrong question. A signature may help detect a modified file without establishing that the query selected every required withdrawal. A warehouse may return consistent rows without preserving the source assessment that justified a decision. A federation layer may expose current information while depending on a provider that will not be available during a later review.

The companion guide on choosing a CASP evidence store addresses where reconstructable records live. Here, assume that records exist and examine how a bounded set leaves that environment. The earlier policy-to-production control trace supplies the connection between a control obligation and its evidence. An export needs to preserve that connection through delivery.

Fix the request before comparing architectures

A crypto-asset service provider should define the recipient, authorized purpose, record classes and disclosure boundary before selecting an export path. An internal investigation, supervisory request and supplier handover may require different populations and permissions. A reusable export service can support all three while keeping their approvals and delivered versions separate.

Commission Delegated Regulation (EU) 2025/1140, Article 2, links record retention to ready access, reconstruction of processing stages and ascertainable corrections and prior contents. It also addresses protection against manipulation and efficient analysis. Those outcomes inform the comparison; they do not certify one of these architectures. The responsible compliance owner must determine the applicable record classes and any prescribed delivery format.

Use one request envelope for every candidate arrangement. Record six elements: the request identifier and version; the legal-entity and business population; the event period and knowledge cutoff; the permitted fields and redaction policy; the expected source systems and their completion criteria; and the reviewer-approved delivery and verification requirements. Retain this envelope with the export, not only in the ticket that initiated it.

Define time explicitly. The event period selects business activity. The knowledge cutoff limits which observations or corrections were available to the exporting system. A source watermark describes how far ingestion has progressed under that source's delivery contract. The export creation time says when packaging finished. These values can differ, and one timestamp cannot truthfully stand in for all of them.

1. Snapshot export: a frozen answer to a bounded question

A snapshot architecture selects an approved population from a defined source state, materializes it and delivers the resulting files with selection metadata. Its strength is a stable review object: the recipient can inspect the same contents tomorrow without rerunning a live query. This often suits a specific period, account population or incident boundary.

Delivered artifact: Include the extracted records, field definitions, request envelope and source-state reference. Preserve the extraction query or an equivalent versioned selection specification. A spreadsheet or JSON file with a creation date alone does not explain the database state from which its values came. Where fields are derived, identify the rule that produced them.

Temporal boundary: Establish a consistent read within the relevant source or use an application-defined freeze. Several independent databases do not acquire a common transaction boundary merely because their exports started together. If no global snapshot exists, preserve each source's cutoff and demonstrate why the combined result answers the request despite that limitation.

Recipient dependency: A self-contained snapshot is convenient for inspection but can lose the history behind current values. Include prior versions or references when the request asks why a decision was made. A reference is useful only if the recipient can resolve it under the agreed review conditions; an inaccessible internal identifier is not supporting evidence.

Failure test: Update one source halfway through extraction and verify that the delivered population does not silently mix old and new interpretations. Then request the same approved version again. Decide whether acceptance requires identical bytes or the same records and meanings, since file ordering and harmless formatting can change bytes without changing the answer.

Choose this pattern when a frozen bounded answer is sufficient and its provenance can travel with it. Reject a latest-state snapshot when the question requires amendments or historical knowledge that the snapshot does not retain.

2. Event-log export: the sequence behind the answer

An event architecture exports a bounded history of observations and decisions, with the schemas and interpretation rules required to reconstruct the requested state. It is useful when the reviewer must follow transitions, distinguish corrections from original facts or determine what a service knew before acting. An operational message dump is only the starting material.

Delivered artifact: Supply event identities, source identities, business references, relevant payloads and correction links. Document the ordering guarantees that actually exist. A partition offset can establish position within that partition; it does not automatically establish causal order across unrelated producers. Include the baseline state when replay begins after the business object's creation.

Temporal boundary: Preserve occurrence, receipt and effective times according to their meanings. Export the events admitted by the request's cutoff, while identifying relevant later corrections separately if the approved request calls for them. Never insert a late-arriving correction into an earlier knowledge view simply because its business-effective time is earlier.

Recipient dependency: The recipient may need a projection definition, reference data and historical policy versions. Prefer a documented reconstruction procedure with test inputs and expected outputs over a requirement to run the supplier's whole production environment. If executable code is supplied, review it through the recipient's normal security process rather than treating a signed archive as permission to execute it.

Failure test: Remove a required baseline or one decision event and check whether reconstruction identifies the gap. Repeat delivery of an event and confirm the declared identity rule prevents it from becoming an additional business action. A plausible reconstructed state is not enough if missing history can pass unnoticed.

Choose event export for questions about sequence and historical interpretation. Price the maintenance of schemas and replay dependencies into the decision. A compact event file can impose more reviewer effort than a larger snapshot when its meaning depends on undocumented application behavior.

3. Warehouse extract: an analytical view with source lineage

A warehouse architecture selects evidence from a consolidated analytical model, usually after ingestion and transformation from several operational systems. It can make population checks, joins and aggregate investigation practical. Its principal risk is that an analytically useful representation may omit details needed to substantiate individual decisions.

Delivered artifact: Provide the selected rows, query version, transformation versions and field definitions, together with references to retained source records. Label computed classifications and aggregates as derived. For each important result, the reviewer should be able to distinguish a source assertion from a value created by a transformation or a later reconciliation rule.

Temporal boundary: Record ingestion watermarks and the warehouse state used by the extract. A query completed at noon does not establish that every source had delivered records through noon. If historical queries are supported, verify the retention and semantics of that history rather than assuming that a feature name guarantees the required knowledge view.

Recipient dependency: Common tabular formats can reduce tool dependency, but normalized values still require interpretation. Preserve units, precision, timezone conventions and the meaning of missing values. An empty field may mean not applicable, not received or withheld. Collapsing these states into one blank can change the conclusion of an audit reconstruction.

Failure test: Reconcile business identifiers against an independently defined source population and trace a disputed row back through its transformations. Then alter a mapping rule and check that the old delivered result remains explainable. Matching totals do not prove matching populations: a duplicate can offset a missing record.

Choose a warehouse extract when cross-system analysis is the dominant review task and retained source versions remain accessible. Reject it as a complete evidence package when it supplies attractive summaries without the lineage or source detail required by the request.

4. Signed evidence bundle: a verifiable delivery unit

A signed-bundle architecture collects approved records and explanatory metadata into a package whose contents can be checked against an authenticated manifest. The bundle is the delivery unit; its contents still come from a defined extraction process. It is particularly useful when custody crosses organizational boundaries or the recipient needs to verify an export without the producer's dashboard.

Delivered artifact: Bind the request version, file inventory, content digests, schema references and declared exclusions into the protected manifest. State exactly which bytes the signature covers and how the recipient obtains a trusted verification key. If metadata can be changed without invalidating verification, identify that boundary explicitly. Avoid describing the entire package as authenticated when only one payload file is signed.

NIST's Digital Signature Standard, FIPS 186-5, published February 3, 2023, states: “Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory.” This explains the signature's job. It does not establish that the issuer captured every relevant event, selected the correct population or interpreted the records accurately.

Temporal boundary: Preserve extraction cutoffs separately from the packaging and signing times. Signing today's export cannot prove that every included assertion existed yesterday. Where independent time evidence is required, define and validate that requirement separately rather than relying on the producer's own timestamp.

Recipient dependency: The recipient needs the bytes, format specification and appropriate trust material. RFC 8493, the BagIt file packaging format, provides a useful reference for payload inventories and checksum validation. Its complete-and-valid distinction concerns the package's declared files; it does not establish a complete business population. A checksum manifest also needs an authenticated reference if an attacker could replace both the files and their listed digests.

Failure test: Change one payload, remove a listed file and substitute a different manifest. Verification should distinguish these failures. Separately omit a required business record before creating an internally consistent package. The completeness check must catch that omission even when every delivered digest and signature verifies.

Choose this pattern when independent verification of the delivered artifact matters. It commonly wraps one of the other four arrangements. Keep privacy controls separate: signing does not encrypt data or authorize its disclosure.

5. Federated query: distributed ownership with a frozen result

A federated architecture routes an approved evidence request to several source systems and assembles their responses. It can reduce unnecessary central copying and preserve local ownership of sensitive records. The challenge is to turn a collection of independently timed responses into an honest, reviewable result.

Delivered artifact: Retain the request sent to each source, response identity, source cutoff, authorization decision and completion status. Materialize the assembled response when the reviewer needs a stable delivery. A bookmark to a live federated query cannot preserve what an earlier recipient saw if the sources or access rules subsequently change.

Temporal boundary: Define the consistency model across sources. If they cannot answer the same historical cutoff, report their separate boundaries and the resulting limitation. Do not label the output a single coherent snapshot merely because the orchestration layer finished successfully. Its success may mean only that it received some responses.

Recipient dependency: Live federation remains exposed to source outages, account changes and retention decisions. A frozen assembled bundle can remove some of that dependency, provided it contains the permitted evidence and interpretation material. Where originals must remain local, specify a controlled retrieval route and the consequences if that route becomes unavailable.

Failure test: Make one required source unavailable and inspect both the interface and exported metadata. The result must identify the missing source and affected population. An empty response must remain distinguishable from a timeout or access denial. Retrying the request must not mix a new response from one source with an old response from another without recording that composition.

Choose federation when distributed control is a real requirement and source completion can be proven for the request. For an external handover, combine it with materialization and a declared verification procedure. Reject a partial result presented as a completed export.

Run the same request through every pattern

Use a small fictional fixture before comparing scale or cost. Request R-42 covers withdrawals W-101 through W-104 for one declared event period, with a knowledge cutoff of 12:00 UTC. The authoritative withdrawal register establishes those four identifiers. Decision evidence comes from one source; custody acknowledgements come from another. The reviewer requires a record-level explanation, not merely a total.

At 11:55, the decision source records assessment A-1 for W-103. At 12:05, it receives correction A-2 with an effective time of 11:50. Export E-1 answers the 12:00 knowledge request, so A-1 belongs in that historical explanation. A later export E-2 may answer a revised 12:10 request and disclose A-2. Keep the two request versions explicit rather than replacing E-1 under its original identifier.

Now withhold the custody acknowledgement for W-104 and supply W-102 twice. A naive row count can still report four. Comparing identifier sets exposes W-104 as missing and W-102 as duplicated. Reconciliation must also distinguish business objects from their legitimate multiple evidence records: four withdrawals do not imply that the finished package should contain exactly four files or events.

Every architecture must expose these same facts, but its weak point differs. A snapshot can freeze the wrong state. Event replay can apply the correction at the wrong knowledge cutoff. A warehouse can conceal the missing acknowledgement behind a join. A signed bundle can authenticate an incomplete selection. Federation can interpret an absent source as an empty result. These are proposed failure injections, not observations about named products.

Retain a short acceptance ledger for the exercise:

Population: Expected identifiers, delivered identifiers, missing and duplicate classifications, and the independent source of the expectation.
Time: Event period, knowledge cutoff, source watermarks and evidence showing how the late correction was treated.
Interpretation: Source versions, transformations and the recipient's ability to explain W-103 without access to an undocumented production service.
Integrity: Inventory and byte-verification results, with signature verification where the chosen design uses it.
Completion: Required-source statuses and the effect of the missing W-104 acknowledgement on release approval.
Reissue: A new export identifier, its relationship to the previous delivery and the reason the account changed.

Mark a result unverified when the demonstration cannot exercise it. A failed mandatory condition remains failed even if the arrangement performs well on cost or query speed. Keep the failed artifacts when a fix is retested so the acceptance history explains what changed.

Protect the recipient boundary

Export authorization needs to follow the data into packaging and download. A user permitted to query aggregate counts may not be permitted to receive underlying identity documents. Apply approved field and record restrictions before release, and check temporary download links, manifests and filenames for unintended disclosure. Inventory metadata can itself reveal customer or investigation details.

Keep redaction attributable. Preserve a protected relationship between a redacted delivery and its originals, the policy version and the approving role. The recipient should understand the kind of information withheld without gaining access to it. Retain the unredacted records only under the approved policy and access boundary; the export workflow should not create an uncontrolled parallel archive.

Treat incoming bundles as untrusted files even when their signatures verify. Validate archive paths, size limits and file types before extraction or opening. Do not let a manifest direct writes outside the designated review directory or fetch arbitrary remote locations. RFC 8493 explicitly discusses path and retrieval risks; package validation and content safety are distinct from verifying digests.

Long-running exports need an authorization check at release as well as at job creation. A request may be canceled, narrowed or reassigned while extraction continues. Bind the approved recipient and permitted scope to the final export version, and define what happens to material generated under an obsolete approval. Finishing a background job should not automatically authorize disclosure. Keep a canceled delivery distinct from a failed extraction so operators do not accidentally resend it during recovery.

For large packages, design restart behavior around stable part identities and a final completion record. A resumed transfer should identify which verified parts it reused and which it regenerated. If a part changes, its inventory entry and the package version must remain consistent with that change. A recipient who has downloaded several parts still needs an explicit indication that the declared delivery is complete; the absence of another file is not a reliable completion signal.

Record delivery and receipt separately. A successful upload confirms a transport action, while recipient validation establishes whether the intended artifact arrived and could be interpreted. Preserve the received export identifier and validation outcome. If a correction is later issued, use the existing disclosure record to identify affected recipients and have the responsible owner decide the required follow-up.

Select the combination the team can operate

For a recurring analytical request, a warehouse extract with source lineage may be the practical starting point. For a disputed sequence, event history may carry essential information. A snapshot can freeze either result for a bounded review. Add authenticated packaging where independent delivery verification is required, and use federation where ownership or data boundaries justify its extra completion logic.

Where an export joins onboarding, monitoring and custody records, the integration contract determines whether that combination remains explainable. Pharos Production's MiCA compliance software development covers these workflow domains and regulatory reporting. A relevant delivery brief should specify shared evidence identifiers, source completion criteria and recipient verification, with acceptance demonstrated against the CASP's approved request.

Compare costs on the same declared workload. Include source extraction, transformation, retained versions, package construction, transfer, recipient tooling and operational review. Measure a representative retrieval and reissue exercise before estimating capacity. State assumptions separately from measurements; this comparison supplies no invented prices or performance rankings.

Record the chosen extraction path, frozen artifact, verification boundary, unresolved dependencies and accountable owner. Reopen that decision when a source contract, schema, policy or recipient requirement changes. The useful architecture is the one that can deliver an interpretable answer to the approved request and show precisely where its evidence ends.

Sources and review

Primary sources and service scope checked September 19, 2026. Sources are linked beside the relevant passages. The R-42 fixture and acceptance ledger are proposed engineering artifacts, not measured deployment results.

Suggested citation: Dmytro Nasyrov, Five CASP Evidence Export Architectures Compared, Pharos Production, September 19, 2026. CASP evidence export architecture comparison.

About the author

Portrait of Dmytro Nasyrov wearing a dark suit and light blue shirt against a dark background.

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.

Page updated

Report abuse