Is EEI a replacement for telemetry?

No. Telemetry and EEI serve different functions in the same stack. Telemetry gives the operator probabilistic risk signals — behavioral patterns, device reputation, cross-session velocity — that EEI does not produce. EEI gives the operator a cryptographic record of what the device's runtime observed at the moment of execution — independently verifiable by issuers, schemes, and regulators without routing through a vendor. Most Tier-1 deployments need both.

What does telemetry do that EEI does not?

Telemetry aggregates signals across time and devices. Behavioral biometrics, device reputation built from cross-merchant observations, interaction timing, session velocity — these probabilistic, aggregated signals are what telemetry vendors specialise in. EEI has no cross-customer signal aggregation, no behavioral biometrics layer, and no pattern-of-life model. For those capabilities, a telemetry SDK is the right tool.

What does EEI do that telemetry does not?

EEI produces a signed, device-bound execution record that any party with the operator's public key can verify independently — no vendor mediation required. In a dispute, the issuer verifies the token directly against the operator's public key. In a scheme audit, the reviewer replays the hash chain. In any of those cases, the operator presents the token without calling a vendor API. Telemetry risk scores don't travel that way.

Yes — and the natural composition routes both to the operator's risk engine. Telemetry provides the probabilistic risk signal; EEI provides the deterministic evidence record. The risk engine reads both; the evidence store retains EEI tokens for dispute and audit consumption downstream. The two don't conflict — they cover different parts of the trust question.

Why does the verification path matter for disputes and compliance?

An EEI token is verifiable by any party that holds the operator's public key — issuer, dispute platform, scheme reviewer, regulator — without the operator calling a vendor API to re-derive the verdict. That matters when the vendor is unavailable, when the verifier doesn't have a relationship with the vendor, or when the chain of custody must be independently auditable. Telemetry scores are optimised for real-time risk decisions; they are not structured for post-hoc independent verification.

We already instrument our mobile app with OpenTelemetry and send traces to our SIEM. What does EEI add?

OTel spans record what your SDK reported to the collector — they are not signed at source by the device. Your backend trace proves that a request arrived and was processed; it does not prove what the device's execution environment looked like at the moment the user acted, whether the payload was assembled by the legitimate app, or that the credential interaction was unmediated. EEI's signed tokens fill that gap: each event is signed on the device with a key bound to the platform key store, carries a trust_basis declaration from the runtime coherence monitor, and is hash-linked to the previous event. When you correlate OTel traces with EEI tokens in your SIEM, you gain the device-side evidence layer that OTel was never designed to provide.

comparison · EEI vs telemetry

Signal, meet proof.
Telemetry infers. EEI signs.

Behavioral analytics, device fingerprinting, risk scoring — telemetry assembles its risk verdict at the vendor backend; the inference is not signed at source by the device. EEI signs an execution record on the device at the moment of each security-relevant event, with a key bound to the device's platform key store. Both reach the operator's risk engine; only one can be presented by the operator — to dispute platforms, auditors, and counterparties — without requiring vendor mediation.

short answer

Telemetry is the probabilistic risk layer — behavioral patterns, device reputation, cross-session signals assembled at the vendor backend. EEI is the signed evidence layer — each configured security-relevant event signed at source on the device, hash-chained across the execution sequence, verifiable by any party the operator grants a public key, without routing through YinkoShield.

where each one forms its verdict

EEI signs at source. Telemetry assembles at the vendor backend.

EEI signs evidence at source on the device — no vendor in the verification path. Telemetry assembles its verdict at the vendor backend before passing a risk score to the operator.

side by side

What each one produces. What each one does not.

Dimension	Telemetry	EEI
What it produces	A risk score or device-reputation signal assembled at the vendor backend from signals collected on device. The verdict is a probabilistic inference.	A signed Evidence Token (JWS-compact ES256) produced by the device at the moment of each configured security-relevant event. The token carries a signature that cannot be produced without the device-bound private key.
Where the assertion is formed	The vendor backend: signals are assembled and interpreted at the vendor's infrastructure into a risk inference. The risk verdict is not signed by the device at source.	The device, at the moment of each event. The signing key is bound to the device's platform key store; the signed token is the only artifact that travels to the operator.
Who is in the verification path	The risk score is formed and verified at the vendor backend; the operator cannot independently verify the inference without vendor cooperation.	No YinkoShield endpoint is consulted during verification. The operator verifies against their own stored public keys in their own stack.
Temporal scope	Behavioral patterns accumulated over time: session velocity, cross-session device reputation, interaction timing. Well-suited to pattern-of-life signals.	Event-continuous from session start to submission. Each configured event — credential use, biometric, payload assembly, submission — produces a signed token hash-linked to its predecessor.
Data custody and privacy	Behavioral signals — which may include interaction timing, typing patterns, and device identifiers — are assembled and retained at the vendor backend across the operator's customer base.	Signal classes only — no PII through the substrate.
Cross-fleet signals	A genuine strength: cross-merchant and cross-session device reputation built from observations across the vendor's deployment base. EEI does not provide this.	Does not aggregate cross-customer signals. EEI's value is the per-operator, per-device cryptographic chain — not network-level reputation.
Output portability	A risk score in the vendor's format, verifiable only through the vendor's system. Issuers and scheme reviewers receive the operator's interpretation of the vendor's verdict.	JWS-compact tokens, verifiable by any party holding the operator's public key — issuer, scheme, dispute platform, regulator — without routing through YinkoShield.
Chain of custody	No device-originated cryptographic chain from signal collection to risk score. The score is the vendor's inference; its derivation is vendor-internal.	Tamper-evident hash-linked sequence from the first instrumented event. Each token references its predecessor's hash; within the observed sequence, any suppressed token creates a detectable gap in the hash chain or sequence numbers.
Dispute and audit use	The risk score supports the fraud decision at transaction time. Re-presenting it to an issuer, scheme, or counterparty post-hoc is a vendor-mediated process.	Signed tokens are independently verifiable at any later point — dispute resolution, scheme audit, counterparty review — without YinkoShield's involvement, provided the operator maintains their public key registry.
Adoption pattern	Mature; behavioral analytics and telemetry SDKs are widely deployed across Tier-1 payment operators globally.	Emerging category; designed to sit alongside telemetry and produce the deterministic evidence layer that telemetry doesn't ship.

where they compose

Telemetry gives the risk signal. EEI gives the signed evidence record.

A typical Tier-1 deployment runs both. Telemetry feeds the real-time risk engine — behavioral patterns, device reputation, session velocity — informing the allow / challenge / decline decision at the moment of the transaction. EEI signs each event independently, producing a hash-linked execution record that travels separately from the risk score.

What changes when you add EEI to a stack that already runs telemetry:

Disputes resolve against signed device evidence, not a re-presented vendor risk score. The issuer or dispute platform verifies the token directly against the operator's public key.
Scheme and regulatory audits get a cryptographic chain, not a vendor-mediated reconstruction. The hash-linked execution sequence is replayable from the device ledger independently.
The operator's policy engine reads both. Policy decoupling defined on /eei-vs-rasp.

The two are not in competition. Telemetry answers: "what is the probability that this device and this session are legitimate?" EEI answers: "what events did the device sign, with what trust basis, and in what sequence?" Both questions matter for a complete fraud, dispute, and compliance posture.

What about observability tools — OpenTelemetry, APM, SIEM?

Note first that Datadog and New Relic are not only backend APM tools — both ship mobile monitoring and session replay products (Datadog Mobile Monitoring, New Relic Mobile). Those products instrument the app view layer and have the same blind spot as any session replay SDK: OS-layer overlays, accessibility services, and runtime hooks sit below the SDK's observation boundary. The session replay dimension is covered separately in EEI vs Session Replay.

For backend observability specifically — OpenTelemetry, distributed tracing, SIEM — the question is different: what did the backend process, at what latency, with what errors? Distributed traces are the right tool for that. They are not designed to prove what happened on the device before the request left.

Three things an OTel trace cannot tell you:

Whether the execution environment was coherent. An OTel span records that the app called the payment endpoint. It does not record whether an accessibility service was intercepting input, whether the UI the user saw matched what the app rendered, or whether the process had been instrumented by a third party. EEI's runtime coherence monitor observes that and declares it in the trust_basis of every signed event.
Whether the payload was assembled by the legitimate app. The backend trace shows the request that arrived. EEI signs the payload at the moment of assembly on the device. If the two differ, the discrepancy is evidence — not just an anomaly in a log.
Chain of custody for the user action. A distributed trace proves that service A received a request and called service B. It does not prove that a user made a deliberate, uncoerced decision on an uncompromised device. EEI's hash-linked sequence — anchored to device attestation — provides that layer.

OTel and APM are not being displaced here; they remain the right tools for backend observability. The composition is: OTel traces prove what the backend processed; EEI tokens prove what the device signed. The SIEM that correlates both has stronger evidence than one that correlates only backend logs.

frequently asked

Six questions, six answers.

·01 Is EEI a replacement for telemetry?: No. Telemetry and EEI serve different functions in the same stack. Telemetry gives the operator probabilistic risk signals — behavioral patterns, device reputation, cross-session velocity — that EEI does not produce. EEI gives the operator a cryptographic record of what the device's runtime observed at the moment of execution — independently verifiable by issuers, schemes, and regulators without routing through a vendor. Most Tier-1 deployments need both.
·02 What does telemetry do that EEI does not?: Telemetry aggregates signals across time and devices. Behavioral biometrics, device reputation built from cross-merchant observations, interaction timing, session velocity — these probabilistic, aggregated signals are what telemetry vendors specialise in. EEI has no cross-customer signal aggregation, no behavioral biometrics layer, and no pattern-of-life model. For those capabilities, a telemetry SDK is the right tool.
·03 What does EEI do that telemetry does not?: EEI produces a signed, device-bound execution record that any party with the operator's public key can verify independently — no vendor mediation required. In a dispute, the issuer verifies the token directly against the operator's public key. In a scheme audit, the reviewer replays the hash chain. In any of those cases, the operator presents the token without calling a vendor API. Telemetry risk scores don't travel that way.
·04 Can I run both?: Yes — and the natural composition routes both to the operator's risk engine. Telemetry provides the probabilistic risk signal; EEI provides the deterministic evidence record. The risk engine reads both; the evidence store retains EEI tokens for dispute and audit consumption downstream. The two don't conflict — they cover different parts of the trust question.
·05 Why does the verification path matter for disputes and compliance?: An EEI token is verifiable by any party that holds the operator's public key — issuer, dispute platform, scheme reviewer, regulator — without the operator calling a vendor API to re-derive the verdict. That matters when the vendor is unavailable, when the verifier doesn't have a relationship with the vendor, or when the chain of custody must be independently auditable. Telemetry scores are optimised for real-time risk decisions; they are not structured for post-hoc independent verification.
·06 We already instrument our mobile app with OpenTelemetry and send traces to our SIEM. What does EEI add?: OTel spans record what your SDK reported to the collector — they are not signed at source by the device. Your backend trace proves that a request arrived and was processed; it does not prove what the device's execution environment looked like at the moment the user acted, whether the payload was assembled by the legitimate app, or that the credential interaction was unmediated. EEI's signed tokens fill that gap: each event is signed on the device with a key bound to the platform key store, carries a trust_basis declaration from the runtime coherence monitor, and is hash-linked to the previous event. When you correlate OTel traces with EEI tokens in your SIEM, you gain the device-side evidence layer that OTel was never designed to provide.

going deeper

Two questions this page raises but does not answer in full:

What fields are in each signed Evidence Token?: Event type, timestamp source, key ID, trust basis, monotonic sequence number, previous hash, nonce/context binding, app version, policy version, verifier result — the normative field definitions and value constraints are in the YEI-001 specification. The Evidence Token format article covers the public required-claim set.
How is the signing key provisioned — and what happens on reinstall or device migration?: Key generation, hardware-backing guarantees, destruction on factory reset, and the bootstrap attestation chain are covered in Local key custody — device, operator, and vendor boundaries.

Operators that already run telemetry get the most from a 60-minute evidence-layer mapping.

We map your existing telemetry stack to EEI's signal classes and show what changes for disputes, compliance, and scheme audit when signed device evidence enters the picture. You keep the telemetry; you add the evidence record.

Map your telemetry stack to EEI signals

Signal, meet proof. Telemetry infers. EEI signs.