Give Trusted Third Parties (TTPs) such as

Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines

the Data They Need to Approve Transactions

without Interruptions to the User Experience

In some European market’s PSD2’s Strong Consumer Authentication (SCA) are requiring 98% of transactions be interrupted by an authentication challenge. Such interruptions cause cart abondoment and loss of the transaction.

mSIGNIA’s cAPI Data Instructions allow TTPs (such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines) to request the device, biometric, and other risk data they require to enable a safe, SCA-compliant, frictionless approval of valid transactions and virtually eliminate step-ups and other interruptions.

Scroll down to review the design that collects the data required to reduce fraud and approve transactions or click on the icons below to learn more about mSIGNIA product benefits for TTPs…


Transactions are complicated:  risk data is collected from the consumer’s device through the consumer’s connection within the merchant’s browser origin or app… but the data is scored by a Trusted Third Party (a TTP such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines).

EMV 3DS, which stands for 3-Domain Security, is emerging the de facto industry standard for moving such data from the merchant domain to the risk scoring domain, using the payment network domain to make the connection.  3DS is less a true security standard – topics like authentication and transaction risk scoring are outside the spec – and more a data transport standard.  3DS defines the rails on which data moves between merchant and issuers.  When it comes to reducing risk, data is everything.

Historically with browser transactions, TTPs could collect risk data by opening a hidden connection, or iFrame, through the browser.

However, with mobile apps not allowing such 3rd party connections and new browsers increasingly blocking 3rd party functionality, a new paradigm is eminent.

mSIGNIA has proposed a new Client API (cAPI) and Universal SDK (uSDK) framework to enable frictionless approval of transactions regardless of the client platform.

As the diagram to the right shows, TTPs can request the risk data they require through cAPI instructions.  The instructions and resultant data are passed over existing, compliant EMV 3DS rails.

The enhanced data collection is pre-declared by the TTP, without the annoyance of authentication challenges or out-of-band exchanges that cause cart abandonment.

The additional risk data enables compliance with SCA and FIDO; ensuring more frictionless transactions are approved.

cAPI Data Instructions are embedded in EMV 3DS protocol exchanges between the EMV 3DS SDK and ACS; they are invisible to the EMV 3DS Directory Server, the 3DS Server, and the merchant’s iOS and Android mobile apps.

Only mSIGNIA’s cAPI + uSDKs can…

  • Be remotely managed to satisfy the risk requirements of nearly any TTP
  • Collect risk data directly from a merchant’s browser, iOS and Android mobile app
  • Prompt the consumer for a fingerprint or facial biometric without requiring out-of-band processing or a downloaded TTP app
  • Collect data such as dynamic device tags and behavioral biometrics for SCA compliance (link AboutSCA),

Read on to learn more about the 3DS-compliant instructions a TTP can add to EMV 3DS exchanges.

Client API Enhanced Data – mSIGNIA has created a Client API (cAPI) which allows TTPs (such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines) to declare data instructions that collect enhanced data from within the merchant environment.  The enhanced data capabilities enable EMV 3DS, PSD2 SCA, and FIDO compliance.

Data, such as device identifiers and user biometrics, are collected during the transaction and the resultant data is passed in the initial 3DS frictionless exchange; allowing the extra data to be scored by the TTP immediately.  This reduces unnecessary exchanges over (potentially slow, sometimes costly mobile) network connections and nearly eliminates the need for challenges and out-of-band interruptions which cause abandoned transactions… even when authenticating for SCA compliance.

TTPs can also write data to the consumer’s device through merchant exchanges.  This enables 1st party data storage on the device; it will not be blocked by 3rd party cookie blockers.  Proprietary data – such as device identifiers, payment tokens, and crypto keys – can be safely provisioned.  Data provisioning uses EMV 3DS’s well-vetted, academically proven method for encrypting and securely transmitting data between a TTP and an EMV 3DS SDK running in either a browser or the merchant’s app.  Once the data is safely transmitted to mSIGNIA’s uSDK, the uSDK can use native protected memory resources, such as those found in iOS and Android, to securely store the data on the consumer’s device.

To learn more about the Client API and Universal SDKs, click here.

Biometrics including FIDO – Mobile devices ushered in the era of consumer fingerprint and facial biometrics.  TTPs (such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines) can leverage these user-friendly biometric experiences by instructing the uSDK to use system resources to request the consumer re-authenticate to the device with registered biometric.

Such consumer-to-device authentication is a cornerstone for FIDO authentication.  As a FIDO authentication, the FIDO Reliant Party can generate FIDO-required asymmetrical crypto keys on the consumer’s device and request an attestation to the quality of the biometric authentication performed to improve risk analysis further.

TTPs can also use the uSDK to prompt the user to type into their device to capture behavioral biometrics which capture data on typing rhythm, swiping, pressure, and device tilt.

These biometric functions are performed within the merchant’s browser origin or merchant’s mobile app without interruption to the shopping experience.

Other solutions require (1) biometric authentications for 3DS payment be done as a disruptive out-of-band process and (2) the issuer app must be downloaded onto the consumer’s device.

mSIGNIA’s cAPI + uSDK are an easier, faster way to get the safety biometric authentication provides; learn more here.

Frictionless 3DS + SCA Transactions – PSD2 SCA and other transactions using multi-factor authentication cause risk step-up interruptions in 98% of attempted transactions, leading to significant cart abandonment.

mSIGNIA’s cAPI Data Instructions enables Trusted Third Parties (TTPs such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines) to collect and exchange the data they require to approve the transaction as part of the initial EMV 3DS frictionless exchange.

SCA compliant authentication data includes inherence, possession, and knowledge authentication elements based on uSDK collected data such as dynamic device tags, user secrets, fingerprints, and behavioral biometrics.   For more on cAPI Data Instructions which collect SCA authentication data, click here.

Next Generation Design – mSIGNIA products available today are designed to minimize customer effort and change in the future.  mSIGNIA’s products are already compliant with EMV 3DS version 2.2, multi-factor authentication requirements such as Europe’s PSD2 Strong Consumer Authentication (SCA), and (soon) FIDO.  In addition, mSIGNIA’s products are designed for compliance with future requirements such as EMV 3DS v2.3, SRC, and beyond.

TTPs can already use mSIGNIA’s Browser SDK to function as the EMV 3DS Method which uses a hidden iFrame to collect risk data in browser transactions.  The Browser SDK will be standard for merchant’s complying with the next version of EMV 3DS in 2022.  mSIGNIA’s Browser uSDK enables enhanced data collection for complying with SCA and FIDO; learn more here.

Delegated Authentication including FIDO Reliant Parties – mSIGNIA’s cAPI capability provides any TTP a well-defined, consistent interface so that they can be an EMV 3DS Delegated Authenticator for the merchant. TTPs include FIDO Reliant Parties and even Issuers that prefer to get the data within the merchant context instead of having to interrupt the transaction flow with a standard 3DS challenge.

To learn more about Delegated Authentication using the Client API + Universal SDK protocol, click here.