YinkoShield
Brief

comparison · EEI vs RASP

Different decision points.
Composable, not competitive.

RASP enforces locally — block this call, terminate this session, declare this build out-of-policy. EEI testifies — produce a signed record that travels with the transaction, verifiable by any party with the public key. Same threat surface, different decision point. The two compose.

short answer

RASP and EEI are not alternatives. RASP is the inline enforcement layer; EEI is the signed evidence layer. Operators that ship both get on-device blocking and portable, downstream-verifiable evidence the issuer, scheme, and dispute platform can consume independently.

where each one decides

Same flow. Two decision points. One policy engine.

[ what the policy engine receives ] user flow credential biometric payload send EEI · per-action signed evidence payment.initiated tctx · seq=1044 hardware_backed payment.auth tctx · seq=1045 hardware_backed payment.assembled tctx · seq=1046 hardware_backed payment.sent tctx · seq=1047 hardware_backed event_name · tctx · seq · trust_basis · ordered, hash-linked, full context inline RASP · async detection events frida hook action: monitor ? — no tctx — root action: elevate ? — no tctx — debugger action: block ? — no tctx — detection only · no tctx, no event_name ↑ must correlate with user action operator policy engine reads both streams decides downstream EEI: contextual RASP: correlate ext. RASP action verbs: block · allow · elevate · monitor EEI signed event (aligned with user action) RASP detection (async, no tctx) hash-chain
EEI emits signed evidence aligned with each user action, context inline. RASP fires detections on its own cadence; the operator must correlate them with the user flow to know which action they relate to.
side by side

Nine dimensions. Three columns.

Dimension RASP EEI
What it does Detects runtime threats on-device and acts on them locally — block, terminate, force re-auth. Signs the runtime trajectory at execution time and produces a portable record any party with the public key can verify.
Decision point On the device, in the moment. Operator-side, downstream — the operator's risk engine combines signed signals with business context.
Output shape Block, allow, or monitor verdict (often a binary toggle per check). Signed Evidence Token (~200 bytes JWS-compact ES256) carrying signal classes and trust basis declaration.
Who can verify Typically the vendor's console or the operator's RASP integration. Any party the operator grants the public key — gateway, issuer, scheme, dispute platform, regulator.
Vendor-in-the-path Often yes — vendor backend or licence service consulted at runtime. No — verification runs in the operator's stack against operator-stored public keys.
Policy decoupling Per-check switch (enable / disable / monitor); making a check context-aware usually means rebuilding the vendor's engine. Signed signals delivered to the operator's policy engine; conditional, contextual policy is operator-defined.
Forensic depth Internal events; portability across an issuer / scheme boundary usually requires re-signing on the operator side. Append-only hash-linked Local Evidence Ledger on the device; deeper forensic queries go through the Commander channel.
Threat-model coverage Application-layer compromise, debugger attach, hooking, repackaging — handled inline. Same surface, plus runtime coherence across the credential-use → network-receipt interval; same surface produces signed evidence the operator can audit later.
Adoption pattern Mature category; many Tier-1 deployments already run a RASP product. New category; sits underneath or alongside RASP and absorbs the evidence layer that RASP doesn't ship.
where they compose

Inline enforcement plus downstream evidence.

A typical Tier-1 deployment runs both. RASP sits inline in the operator's mobile app and POS firmware to refuse loads, kill processes, and short-circuit obviously adversarial flows before they reach a credential. EEI sits underneath, observing the runtime trajectory across every significant event and signing the result.

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

  • Disputes resolve against signed evidence, not credibility judgment between backend logs and the cardholder's claim.
  • Issuers, schemes, and regulators verify independently — same evidence, different consumers, no re-signing across the boundary.
  • Policy stays with the operator. Signed signals feed the operator's risk engine; conditional, contextual policy replaces RASP's per-check toggle.
  • Vendor outage doesn't break verification. EEI verification runs in the operator's stack against operator-stored public keys; no YinkoShield endpoint is consulted.
frequently asked

Six questions, six answers.

·01

Is EEI a replacement for RASP?

No. EEI and RASP cover different decision points. RASP enforces locally on the device — block this call, terminate this session, declare this build out-of-policy. EEI testifies — produce a signed record that travels with the transaction, verifiable downstream by parties that don't run on the device. Operators that ship both get inline enforcement plus portable, court-grade evidence.
·02

What does RASP do that EEI does not?

RASP can act on-device in the moment — refuse to load, kill the process, block the call, force a re-authentication. EEI does not enforce; it signs. If your threat model needs a runtime that locally blocks rather than reports, you need RASP (or RASP-style controls inside the operator's app).
·03

What does EEI do that RASP does not?

EEI produces signed evidence that any party with the public key can verify — the gateway, the issuer, the dispute platform, the regulator, a partner. The evidence travels with the transaction and is replayable from the device ledger. RASP, by default, produces internal events the vendor's console consumes; the same evidence is rarely portable across an issuer / scheme / regulator boundary without re-signing on the operator's side.
·04

Can I run both?

Yes — and most Tier-1 deployments do. RASP handles the inline block-or-allow decision; EEI produces the record that validates or refutes the decision downstream. The two compose. They are not in competition; they sit at different points in the trust pipeline.
·05

Why is the verification model different?

RASP verdicts are typically consumed by the vendor's policy engine or the operator's RASP integration. EEI verdicts are produced by the operator's own verifier (Python / JavaScript / Go / Java reference implementation), against operator-stored public keys, with no YinkoShield endpoint in the path. That property — sovereign verification — is what lets the same evidence be consumed by issuers, schemes, dispute platforms, and regulators without re-issuing trust through a vendor.
·06

Can the EEI runtime and a RASP SDK coexist in the same app process?

Yes. RASP products typically interpose at the JNI / native-library boundary or via instrumented bytecode. EEI's TRP wraps syscalls, libc, and framework calls — a different layer in the runtime. The two run side-by-side without conflicting hook chains. We've validated coexistence with the major Android RASP families in production estates; specifics covered in mapping briefings on request.

Composing EEI with your existing RASP deployment is one of the briefings we run most often.

Sixty minutes with engineering. We map your current RASP rules to the EEI signal classes they would feed; you keep the rules, the policy, and the verifier.

Request a briefing