comparison · EEI vs session replay
The replay looked normal.
The execution was not.
Session replay reconstructs what the application experience looked like from the instrumented app layer. EEI declares what the runtime execution context looked like when value moved. These are not the same evidence class.
A normal-looking tap on Confirm can be consistent with a genuine user journey. It can also be consistent with automation, overlay abuse, or runtime manipulation that the replay layer was not designed to prove. Session replay explains the journey. EEI signs the execution context.
Session replay reconstructs the application experience from what the instrumented view layer observed. EEI observes the runtime execution context — including runtime conditions outside the replay SDK's normal observation boundary — and declares the result in the trust_basis of every signed token. These are not the same evidence class.
Same transaction. Different evidence layers.
session replay · app view layer
app SDK → wireframe reconstruction → vendor platform
EEI · runtime execution context
TRP observes runtime conditions → signed token → operator stack
A normal-looking replay is not always a trustworthy execution.
Session replay is valuable for mobile engineering, product, support, and UX teams. It helps reproduce errors, understand user journeys, and identify friction in flows. That is exactly what it is designed to do.
But a replay is not the same as execution evidence. Consider an accessibility-service attack.
A malicious service operates at the OS level and can observe or interact with the payment app. The app receives a normal-looking tap on Confirm. The replay SDK records the interaction as part of a normal journey.
That replay may be useful for support or investigation. But it does not, by itself, prove whether the execution environment was coherent when the transaction was confirmed.
EEI approaches the same transaction from the runtime layer. The TRP evaluates configured runtime conditions before and during security-relevant events. When those checks identify a compromised condition, the signed token can carry a trust_basis such as compromised_device.
The replay and the EEI token describe the same transaction from different layers. One reconstructs the app experience. The other is designed to declare the runtime trust state as signed execution evidence.
This blind spot extends beyond security. A replay can show that the journey looked normal, but not whether the transaction was signed offline and queued for later submission, whether a latency outlier happened at the execution layer rather than the UX layer, or whether a device restart interrupted the transaction context mid-flow. These conditions can explain anomalous outcomes in journeys that look normal in replay. EEI can record them as part of the signed execution chain when they are part of the configured runtime observation set.
What each one captures. What each one does not.
| Session Replay | EEI | |
|---|---|---|
| primary use | UX, support, journey debugging | Fraud decisions, dispute resolution, audit evidence |
| layer | App view layer | Runtime execution context |
| output | Reconstructed session journey | Signed evidence token |
| verification | Vendor-mediated replay access | Operator-verifiable signed artifact |
| scope boundary | Not designed to prove runtime trust | Not designed to show the visual journey |
↓ full detail below
| Session Replay | EEI | |
|---|---|---|
| What it captures | The app's rendered view layer — user interactions, navigation events, UI state as observed by the SDK. Output: a reconstructed visual journey, typically wireframe-based. | The runtime execution context — what the device's TRP observed at the moment of each configured security-relevant event. Output: a signed Evidence Token hash-linked to the session. |
| Layer observed | Application view layer: rendered UI, user interaction events, SDK-visible state. Instrumentation is inside the app process. | Runtime execution context — outside the app view hierarchy. The TRP monitors execution context: process integrity, ambient services, overlay presence, hook detection, hardware binding. |
| What it does not see | Not designed to prove OS-level automation, overlay presence, or runtime manipulation as signed execution context. Some symptoms may appear in the replay, but the replay itself does not declare runtime trust. | The visual content of the session. EEI does not reconstruct user journeys, capture UI state, or provide session-level UX telemetry. It produces a runtime coherence record, not a session narrative. |
| Trust declaration | None. Session replay records what the app SDK observed; it does not declare the state of the execution environment. There is no trust_basis field, no signed device assertion. | Every signed token carries a trust_basis declaration from the TRP — hardware_backed, hardware_bound, execution_proof, or compromised_device. This declaration is signed at source on the device; it travels with the token. |
| Output format | A time-ordered sequence of view-layer events assembled at the vendor backend, accessible through the vendor's dashboard. Not a signed device artifact. | JWS-compact ES256 signed tokens, verifiable by any party holding the operator's public key. No vendor mediation required at verification time. |
| Who is in the verification path | The replay vendor's platform assembles and stores the session. The operator accesses it through the vendor's system. There is no operator-verifiable signature from the device. | No vendor mediation required at token verification time. The operator verifies tokens against their own public key registry. YinkoShield is not consulted during verification. |
| Dispute and audit use | A visual record supporting case context — useful for human review. Not a signed device assertion; does not declare the execution environment's trust state at transaction time. | Signed chain of execution records, independently verifiable by issuers, dispute platforms, auditors, and counterparties that accept signed device assertions — without routing through YinkoShield, provided the operator maintains their public key registry. |
| Data profile | View hierarchy reconstruction, user interaction events, navigation paths, and screen content may include PII depending on app instrumentation and vendor retention policy. Assembled and stored at the vendor cloud. | Signal classes only — no behavioral content, no PII. |
Use session replay to understand experience. Use EEI to prove execution.
Session replay routes naturally to engineering, product, and support tooling. When a user reports an error or a flow fails, replay gives the team the visual context to reproduce it. That is the right job for the right tool.
EEI routes to the operator's risk engine and evidence store. Signed tokens are evaluated at transaction time for fraud decisions and retained for dispute and audit use downstream.
When both are present, the composition is additive:
- The fraud analyst can see both layers when the investigation workflow correlates session IDs across both systems. Context from the replay; execution-level declaration from the EEI token.
- Dispute resolution uses the signed artifact, not the visual record. The issuer or dispute platform verifies the EEI token against the operator's public key independently. The session replay supports narrative; the signed token is the evidence.
- Overlay and accessibility-service risk can be evaluated from signed runtime declarations, not only from a reconstructed journey. When configured checks identify a relevant condition, the EEI token carries a trust_basis declaration that the replay SDK was not designed to produce.
Session replay answers: "what did the user experience look like?" EEI answers: "what did the device's runtime observe, declare, and sign at the moment value moved?" Both questions belong in a complete fraud and dispute posture. Neither replaces the other.
What about telemetry and behavioral analytics?
Session replay, behavioral telemetry, and EEI are three distinct layers in the same stack. Telemetry (BioCatch, ThreatMetrix, and similar) provides cross-session behavioral signals and device reputation — probabilistic inference assembled at the vendor backend. Session replay provides view-layer visual evidence. EEI provides runtime-layer signed execution evidence. The comparison between EEI and behavioral telemetry is covered separately in EEI vs Telemetry.
Seven questions, seven answers.
- ·01
Is EEI a replacement for session replay?
- No. Session replay answers: 'what did the user experience look like?' EEI answers: 'was the execution environment trustworthy when value moved?' Both questions are valid; they are answered by observing different layers. Engineering and product teams use session replay to reproduce errors and understand journeys. Fraud, risk, and compliance teams use EEI to verify what the device's runtime declared at execution. Most Tier-1 deployments benefit from both.
- ·02
Can session replay detect overlay attacks?
- Not reliably, and not as signed execution evidence. Session replay records what the app SDK observed — it may surface anomalous UI events or errors in some cases, which can support investigation. But OS-layer overlays, accessibility automation, and runtime manipulation sit outside the normal purpose of replay instrumentation. The replay should not be treated as proof that the device execution environment was coherent. EEI's TRP evaluates configured runtime conditions at the execution layer. When those checks identify a compromised condition — an active accessibility service in a suspicious configuration, overlay presence, hook detection — the signed token can carry trust_basis: compromised_device. That declaration is part of the signed artifact and travels to the operator's risk engine regardless of what the app view layer observed.
- ·03
What is trust_basis and why does it matter?
- trust_basis is a field in every EEI Evidence Token that declares the TRP's evaluation of its configured runtime observation set at the moment of signing. It does not represent an exhaustive attestation of all possible device conditions — it reflects what the configured checks observed. Values include hardware_backed (key verified by hardware attestation), hardware_bound (standard profile, no hardware exportability guarantee), execution_proof (configured runtime checks confirmed coherence at signing time), and compromised_device (configured checks identified an anomaly — accessibility service in a suspicious configuration, overlay presence, hook, or process integrity failure). No session replay tool has an equivalent concept: replay reconstructs the view-layer experience; it does not observe or declare the execution context. trust_basis is what makes EEI tokens useful for dispute and audit — the signed declaration of execution state at each event travels with the token. For the temporal scope of each token's evaluation window, see the Runtime coherence architecture page.
- ·04
What is the accessibility service blind spot exactly?
- On Android, the accessibility framework allows services registered at the OS level to observe UI content and interact with apps on the device — including reading view text, navigating controls, and injecting actions. Legitimate uses include screen readers; malicious uses include transaction hijacking. When an accessibility service drives a payment transaction, the app process sees a normal tap event and the replay SDK records it as a normal user interaction. The service is not visible to app-layer instrumentation. EEI's TRP observes whether an accessibility service is active in the execution context, and depending on the operator's configured runtime policy, this may be reflected in the token's trust_basis. The signed record can then be evaluated by the operator's risk engine independently of what the session replay shows. On iOS, the threat model differs — iOS sandbox restrictions limit the same attack surface — and runtime coherence checks are calibrated accordingly per platform.
- ·05
Can session replay and EEI be used together?
- Yes — and the composition is natural. Session replay routes to engineering and product tooling (Datadog, FullStory, LogRocket). EEI tokens route to the operator's risk engine and evidence store. When a transaction under investigation has both a session replay and an EEI chain, the investigator sees the visual journey and the signed runtime assertion together. The replay provides context; the EEI token provides the execution-level declaration that the replay cannot produce.
- ·06
What about RUM platforms — Datadog Mobile, New Relic mobile monitoring?
- Modern RUM platforms including Datadog's Mobile Monitoring and New Relic's mobile agent include session replay or wireframe reconstruction features alongside performance metrics. The same consideration applies: these tools observe the app view layer via SDK instrumentation. Accessibility services, OS-layer overlays, and runtime hooks generally sit outside the SDK's intended observation boundary. EEI is not a RUM replacement; it produces signed runtime-context evidence for workflows that RUM tools were not designed to serve.
- ·07
Why does the verification path matter for disputes and compliance?
- A session replay is stored at the vendor cloud and accessed through the vendor's platform. In a dispute, the operator presents the replay by referencing the vendor's system — the vendor remains in the audit trail. An EEI token is a self-contained JWS-compact signed artifact: any party holding the operator's public key — issuer, dispute platform, auditor, counterparty — can verify it independently, without calling a YinkoShield API or the replay vendor's platform. That distinction matters when the verifier has no relationship with the vendor, when the vendor is unavailable, or when an independently auditable verification trail is required.
Two questions this page raises but does not answer in full:
- What does the TRP actually monitor at the runtime layer?
- The runtime coherence model — what the TRP observes, how it maps observations to trust_basis values, and how it handles edge cases between profiles — is covered in Runtime coherence and Trusted Runtime Primitive.
- How does EEI relate to behavioral analytics and device telemetry?
- Session replay is one layer; behavioral telemetry is another. The full three-layer picture — telemetry, session replay, and EEI — and how they compose in a Tier-1 operator stack is covered in EEI vs Telemetry.
Already running session replay? A 60-minute mapping shows what the runtime layer adds.
We walk through your current replay and telemetry instrumentation, identify the blind spots at the runtime layer, and show what changes for fraud detection and dispute resolution when signed execution evidence enters the stack.
Map your session replay stack to EEI signals