Mobile app owners are responsible for the operation of their app, the user experience and privacy compliance; all directly affect the app owner’s brand-value. As such, they should manage their app, understanding the code that goes into it and the connections to and from the app. This is in stark contrast to browsers, which are relatively unmanaged connection portals to 3rd-party websites.

As shown in the figure below, mSIGNIA has created a universal SDK, or uSDK, and an SDK Manager to enable the payment ecosystem to benefit from the mobile environment… rather than be limited by it.

The uSDK is mSIGNIA’s 6th-generation SDK; designed first for mobile, always for privacy, and certified EMV 3DS compliant for all six payment networks (i.e. Amex, Discover, JCB, Mastercard, UnionPay & Visa). The uSDK enables merchants to integrate a single SDK into their website, iOS app or Android app and support the data requirements of any issuing bank’s risk-engine… ensuring the necessary data and device tags are passed on the initial, frictionless request so more transactions are approved without bothering the consumer.

Since the merchant website or app collects the data, ensuing a user’s privacy is critical to consumer trust, compliancy law and the merchant brand. mSIGNIA’s multi-party, remotely configurable uSDK allows controlling which data is collected and passed according to international privacy laws and merchant rules. The uSDK is also designed to limit the number of off-device connections a merchant’s app initiates to control data exposure.

mSIGNIA SDK Manager Features
Enabling EMV 3DS issuing banks to collect, trust, and risk-score the data they require maximizes the number of transactions approved without challenge. mSIGNIA provides an SDK Manager for facilitating these enhanced capabilities of a uSDK when integrated and deployed in-field as part of a mobile app; together the uSDK and SDK manager enable:

Tagging a Device through a Mobile App

The EMV 3DS specification secures browser payments and, for the first time, in-app mobile payments. For 3DS version 1 and 2, the processing flows for transactions performed in the browser are similar; whether it is a browser on a laptop or a mobile device. With payments from within a mobile app, however, different capabilities between the browser and mobile app platforms require different security methods. As shown below, an issuing bank is allowed to directly connect to the browser and exchange any proprietary device data it requires to authenticate the device and user.

Nearly all of today’s issuing banks store proprietary data (i.e. tags or cookies) on the consumer’s device which ID the device and score risk. Issuing banks, or their vendors, have different proprietary tags and data sets.

The figure above also shows there is no EMV 3DS specification allowing the issuing bank to directly exchange data with the merchant’s mobile app. When an issuing bank requires proprietary data or provisioned tags from a mobile app to reliably score risk and ultimately approve the transaction, it must either:

• Challenge the transaction (directly or out-of-band) which introduces friction and causes cart abandonment, or
• Require a proprietary iOS or Android SDK be integrated within the merchant’s app to either exchange the data directly or through a nearly invisible iFrame^® browser session opened for communication.

mSIGNIA recognized the need for exchanging data with mobile apps and created the uSDK and SDK Manager to configure and provision data when EMV 3DS payment is done within a mobile app. This enhanced data is available in the initial EMV 3DS payment request, so the required data is immediately available to the issuing bank’s risk scoring engine; challenging the user is not required.

mSIGNIA’s SDK Manager can perform data I/O using a compliant EMV 3DS browser method so that an issuing bank can maintain a single data I/O interface; little if any changes to a compliant 3DS issuing bank are required for provisioning a tag to identify the device.

For more trusted and secure provisioning requirements such as payment tokens and cryptographic keys, more robust, strong, mutual authentication options are available to securely exchange provisioning data between the issuing bank and mSIGNIA’s SDK Manager.

For all exchanges between the uSDK and SDK Manager, the integrity of the mobile environment is validated and mutual authentication between client and server is performed.

Data provisioned to the mobile device is stored in protected memory on the device. On iOS devices, this is the KeyChain^®, an academically-reviewed, cryptographically reliable secure storage container. On Android devices, the KeyStore^® is used; because KeyStore lacks the low-level security coordination KeyChain has, it is recommended that a white-box crypto container be used when provisioning high-security data to any device other that does not have a KeyChain.

mSIGNIA’s uSDK supports multiple SDK Managers which may run as web services at various entities.

iOS Device Identification

mSIGNIA and Apple^® both share a great respect for privacy. Apple’s privacy efforts (and business differentiation) include eliminating the access to the hardware serial number-style data typically used to identify a device. In payment risk efforts, this causes many iOS devices to look alike; a big problem in fighting fraud.

EMV 3DS is the first payment specification that describes the data to be collected for identifying the device. Unfortunately, for iOS devices, this data is insufficient to reliably identity a device; as the table below shows, it is almost trivial to make an iOS device unrecognizable. Without reliable device identification, device reputation becomes meaningless and fraud from account takeover increases.

Of the 25 iOS data values EMV 3DS specifies, only 5 are meaningful – but problematic – for unique device identification:

• Ad ID – Apple requires the app serve advertisements to use this identifier; ads are unusual in a merchant’s app. The user can disable or change the Ad ID through simple configuration settings
• Device Name – How many “Bob’s iPhones” are there? Plus, the name is easily changed through configuration.
• IP Address – With Apple, the IP Address is assigned by the ISP or mobile operator and the user can request a new assignment at any time. Care must be taken to resolve network cloaking technologies like TOR and proxies.
• Location – GPS coordinates are a great identifier, but they can be easily disabled by the user or power-saver settings and care must be taken regarding user privacy
• App ID^® – Apple provides developer’s the App ID identifier as a replacement to hardware identifiers. However, a different App ID is assigned when the user uninstalls and re-installs the merchant’s app; eliminating the reliability of a device reputation

Ironically, even though Apple takes hardware identification away, they provide a world-class secure container, KeyChain, for storing tags that can identify the device, but only if an EMV 3DS issuing bank can access the KeyChain through the merchant’s app.

mSIGNIA’s SDK Manager enables an issuing bank to provision a device tag through a merchant’s mobile app into the protected memory on the consumer’s device. mSIGNIA proxies a compliant EMV 3DS browser method so that an issuing bank can use the same JavaScript^® method to write device tags to browsers and mobile apps.

For all exchanges between the uSDK and SDK Manager, the integrity of the mobile environment is validated and mutual authentication between client and server is performed.

Mobile App Security

Nearly every merchant and bank validate the integrity of a PC connecting to their website; the OS, malware and network cloaking are evaluated to protect the web service. Most merchants are not as sophisticated with validated access through their mobile app. In EMV 3DS, the merchant website is the primary connection point, a compromised mobile environment puts the data collected – and ultimately the payment – at risk.

mSIGNIA’s mobile App Point Protection establishes a trustworthy connection between an iOS or Android mobile device and a merchant’s website by evaluating:

mSIGNIA’s EMV 3DS Server and Requester replace the 3DS v1 merchant plug-in. mSIGNIA offers a complete EMV 3DS merchant solution; alternatively, mSIGNIA’s Data Gateway can be easily integrated with other EMV 3DS compliant 3DS Servers when the uSDK is integrated in the merchant’s mobile app. The gateway pre-processes device and transaction data before it is sent for EMV 3DS processing. This enables the merchant to control the consumer data being used and enables 3DS enhancements detailed later.

mSIGNIA’s Data Gateway is easily integrated between an EMV 3DS Server and the merchant plug-in (both shown in tan in the figure below) responsible for communicating with mSIGNIA’s uSDK. The Data Gateway is passed an EMV 3DS standardized AReq sent by mSIGNIA’s uSDK which contains the data from the device (including any data configured for collection by the issuing bank), this data can be altered and augmented as required with data from the merchant.

For all features below, Data Gateway enables the pre-processing of EMV 3DS data before sending the resultant data payload onto the 3DS Server and, ultimately, to the 3DS ACS for scoring.  In this manner, Data Gateway enables a merchant to manage the data sent into the EMV 3DS ecosystem and leverage the data for their own business requirements.

Single SDK Integration

EMV 3DS’s inability to exchange data between an issuing bank and the mobile app performing a transaction will almost certainly cause industry confusion, reluctance, delays and possibly diminish the success and acceptance of EMV 3DS.

It is not likely that every issuing bank will build and require their own EMV 3DS SDK, but various 3DS ACS risk engine vendors may require their own SDK. Failure by a merchant to integrate the proper, customized SDK will prompt unnecessary transaction challenges and complications that will certainly reduce the adoption and success of EMV 3DS.

mSIGNIA’s uSDK is a single SDK that can be remotely managed to satisfy the risk requirements of nearly any issuing bank. The uSDK is a 6th generation SDK which is easy to integrate; it has been available for years and widely used in both iOS and Android mobile applications.

Two of the four US credit card companies have recognized mSIGNIA’s mobile leadership and selected mSIGNIA’s SDK for their EMV 3DS solutions.

Data Control

Data is becoming the most valuable substance, the “new oil” according to industry jargon. Everybody wants consumer data, but privacy regulations, fair-use policies and consumers are increasingly demanding responsibility for data collected. There are legal responsibilities and liabilities for the party collecting a consumer’s data; including stiff penalties when access and management of data is abused.

Many consumers do not realize that when an 3DS transaction done in a browser, the risk data collection is actually performed by their issuing bank, not the merchant’s shopping site; making the bank (not the merchant) liable for data privacy.

When a consumer transacts through a mobile app, the data responsibility is even less understood. EMV 3DS complicates this further; SDKs can collect any data for which the app has requested and cipher the data so that the merchant cannot know the data being passed through the merchant’s environment.

It would be easy for a consumer – and possibly courts – to hold a merchant responsible for abusive data processing even though the merchant was entirely unaware.

mSIGNIA’s uSDK and Data Gateway resolve this issue by enabling the merchant to:

• Configure and control the data collected from the consumer’s device, and
• Modify the payment data being sent from the merchant site via the EMV 3DS protocol chain.

When a merchant is in control of the data being collected and sent through its storefront, they can protect the consumer and more comfortably pass the proper data over EMV 3DS so that the transaction is approved.

Payment Selection

Many EMV 3DS SDK’s will cipher the data collected in the merchant’s app and form the EMV 3DS message passed by the merchant. This prohibits the merchant from processing the collected data and EMV 3DS message in any way.

Not all data a merchant and consumer wish to use for payments is stored at the device; server wallets, card-on-file and even the selection of credit or debit payment is driven by data on the merchant’s commerce server.

mSIGNIA’s uSDK and Data Gateway enable the merchant to decrypt the data from their mobile app and create an EMV 3DS protocol message using both client and server data that conforms to the payment business rules the merchant desires, this includes:

• Adding transaction data from card-on-file, server wallets and subscription or managed payments
• Selecting which payment method (i.e. credit or debit) to use on dual-branded cards

A merchant’s choice in selecting credit or debit processing is often driven by business rules based on cost and risk. A 3DS Server can connect to various payment networks because ech payment network requires the data be encrypted specifically for that network.

3DS v1 and v2 Hybrid

While EMV 3DS is certainly an improvement in security and convenience for all online transactions including payments performed in a mobile app, not all merchants and issuing banks will immediately – or uniformly – convert their 3DS 1.x solution to a 3DS 2.0 deployment.

Therefore, the ability for 3DS v1 and 3DS v2 to co-exist is critical for widescale market adoption and overall success. The 3DS v1.x and 2.x co-existence should not require the consumer to perform any additional action; indeed, the consumer should be unaware they are using two different 3DS versions. By definition, the co-existing solution can make no changes to the existing, installed 3DS v1 component.

mSIGNIA supports two ‘hybrid’ modes:

• A merchant with a 3DS v2 SDK and Server requesting authentication from an issuing bank with a 3DS v1 ACS
• A merchant with a 3DS v1 MPI requesting authentication from an issuing bank with a 3DS v2 ACS

With an EMV 3DS “version 2” merchant, there are two methods for getting payment approval from a 3DS version 1 issuing bank:

1. The merchant app can launch an invisible browser to complete the 3DS version 1 authentication
2. A merchant web service can act as a proxy for the client device and browser using data sent in the EMV 3DS Frictionless Flow

EMV 3DS is an entirely new payment security standard, including new functionality like mobile in-app payments and new protocols that share data across the ecosystem. The effort has been delayed six-months but is now available in-market with the earliest adopters; many organizations are planning their EMV 3DS support and many others are watching results from the sidelines.

mSIGNIA recognized how import demonstrating an operational EMV 3DS ecosystem was to garner industry interest, support, and ultimately adoption. The reference merchant shopping environment – including browser, mobile-assisted browser and mobile app shopping – was so successful in promoting EMV 3DS that mSIGNIA was asked to productize the demo by one of the largest payment networks in the world.

EMV 3DS Reference Merchant

3DS stands for ‘three domain security’ with the domains being: Merchant, Payment Network and Issuing Bank. By far the biggest changes required to implement EMV 3DS are performed by the merchant; the payment network’s directory server still routes data between merchant and bank and the issuing bank scores data it has historically scored, albeit now standardized and passed in the initial payment request.

Many merchants have only recently released their mobile app; the mobile learning curve is still very-much a work in progress. Enabling payment security within such a new environment is a large and poorly understood effort; fortunately, mSIGNIA has been helping developers protect their mobile apps for years.

mSIGNIA’s Compliancy Platform addresses these merchant concerns by providing referenceable storefront environments for the browser, the iOS mobile app, the Android mobile app and even the merchant’s back-end commerce server. The fictitious “Flatirons Outdoor Gear” contains buildable, reusable code for all deliverables that integrate EMV 3DS components.

The Compliancy Platform is a wonderful tool for EMV 3DS awareness and education, it even allows visibility into the data being exchanged over the EMV 3DS protocols.

Validating EMV 3DS Protocol

EMV 3DS is a global payment security standard; as such, components from various vendors must interoperate.  To accomplish interoperability – while leaving flexibility to competitively differentiate – strict adherence to the EMV 3DS protocols must be validated and certified.

mSIGNIA was an early 3DS version 2.1 tester for EMVCo. Having 6th generation SDKs for browser, iOS and Android allowed mSIGNIA to rapidly create the EMV 3DS SDK and work with groups to fine-tune both the protocol and compliance testing of said protocol. In addition to the SDKs, mSIGNIA also did early testing for the merchant’s EMV 3DS Server, especially since it is the communication point for EMV 3DS SDKs.

In gaining this expertise, mSIGNIA realized that a true compliancy web service, emphasizing assurance on mobile-related protocols, was needed to accelerate industry adoption. Actual mobile apps were ‘packaged’ in web-interfaces accessible and controllable via a browser so that EMV 3DS vendors could exercise various scenarios and use cases to certify EMV 3DS protocol compliance.

Merchants, issuing banks and even EMV 3DS vendors can use mSIGNIA’s EMV 3DS Compliancy Platform to validate their implementations and review reports on the validity of data formatted for the EMV 3DS protocol, including the enhanced protocols required for Verified by Visa® and Mastercard SecureCode®, both contain extended program rules for EMV 3DS.

mSIGNIA’s Enhancements to Basic EMV 3DS

Before the EMV 3DS specification, mSIGNIA existing products were targeted towards security-conscious mobile app developers (e.g. banks, payment providers) who required mobile-first, privacy-by-design, advanced authentication. mSIGNIA’s involvement in EMVCo as a Technical Associate defining the EMV 3DS specification has prompted these products to be re-architected and better aligned with the EMV 3DS ecosystem.

The uSDK was an EMV 3DS improvement on our 5th-generation iOS, Android and Browser SDKs. Various mobile-first and data management server capabilities have been separated into microservices which are easily callable by any web service, including competitive 3DS solutions. The administration of the SDKs has migrated into a sophisticated, secure, multi-party solution which includes SDK Manager and Data Gateway. The EMV 3DS Server and EMV 3DS Compliancy Platform are productizations of early proof-of-concept frameworks mSIGNIA built before 3rd-party demonstrations and testing was available.

The figure below shows mSIGNIA components in orange boxes to achieve various mSIGNIA enhancements within in a standard EMV 3DS merchant or banking solution, which are shown in grey boxes: