Although EMV technology brings a lot of advantages, one side effect with it is the increasing number of field issues and complications of management of them. The field issue means that there is something unusual during an EMV contact/contactless transaction which may potentially be the reason for a transaction decline or negative user experience. Field issues may be on a wide range, from a simple incorrect message on the terminal screen, a frozen terminal screen, card reading issues, delay in the transaction time, or frequent declines of transactions.
There are lots of data elements, flows, algorithms used in an EMV transaction which may potentially cause unexpected and unpredictable issues and situations. There might be a different kind of issues related to the hardware, user behavior, EMV L1, and EMV L2. EMV L2 kernel is the main engine running an EMV transaction and it can detect many anomalies and issues during a transaction. However, most of the L2 kernels embedded in the POS terminals are not developed in such a way to analyze and report those kinds of issues. There are different reasons for this. One reason is the limited processor and memory capacity of secure processors where embedded kernels run in. So every additional operation on the processor contributes to the processing time and consumes additional memory. Another reason is most of these kernels were developed at the initial times of EMV without knowing merchant expectations and issues in the field. These kernels were generally developed with the perspective of ensuring a successful L2 kernel certification. Actually, in the initial times of EMV, these field issues were not so common and known. Especially, with contactless L2 kernels coming in the market, field issues have come to the rise. Unlike EMV contact kernel, contactless kernels have different specifications, flows, rules, algorithms, and data elements. And with the mobile wallets, these issues have increased even more. Mobile wallets have additional data elements and new kinds of user experiences such as consumer device cardholder verification methods like face id and fingerprint.
When an EMV card is inserted/presented to the terminal, EMV L2 kernel starts running till the end of the transaction executing all EMV related transaction flows. This gives the opportunity to detect field issues that are generally not logged and monitored by the existing embedded L2 kernels today. This is mainly because of the limited memory size of the secure processors where EMV L2 kernel runs in. If the kernel would log every detail of a transaction, this log should have been stored in the limited secure processor memory. One alternative solution to this issue might be sending these logs to the host rather than keeping in the device, however, it requires the implementation of additional logic on the terminal to send these logs to the host and developing a cloud solution to analyze and monitor logs coming from terminals. Today, this is almost impossible since L2 kernels don’t provide enough data to analyze and monitor these issues.
Ultimately, we can easily say that the field issues can’t be addressed in a good way today. There are lots of different scenarios encountered in the field resulting in transaction declines and bad user experiences. Merchants, acquirers, and other players all suffer from these. For example, sometimes users pull out the card before the transaction is completed and this is mostly not known and monitored by acquirers/POS vendors. Sometimes, there is a missing parameter in the EMV configuration file, which becomes the reason for transaction declines and it is not easy to figure out why this happens. Sometimes, the cards are incorrectly personalized to result in transaction declines. And there are many other factors that may be the reason for these issues.
Fairbit Kernel-in-the-Cloud solution is designed to provide advanced transaction data to detect, monitor, and fix the field issues. Unlike embedded kernels, EMV L2 kernel runs in the cloud in the Kernel-in-the-Cloud solution. The kernel is not dependent on the device limitations such as processing capacity or memory. The solution goes far beyond EMV standards and logs every detail during the transaction. This log data is saved in the cloud database for troubleshooting, monitoring, and reporting. The issues are detected immediately during the transaction time. There is no need to send these data to the cloud after the transaction or at the end of the day which is the case for embedded kernels.
Having all transaction data and logs in the cloud gives numerous opportunities for reporting, monitoring, and instant notifications. Acquirer and POS vendors may be aware of issues immediately by their laptops or mobile phones and take preventive actions before merchants call them.
Kernel-in-the-Cloud not only runs EMV transactions in the cloud but also keeps all of the EMV parameters in the cloud. When a problem is realized requiring a fix in EMV parameters, it can be fixed immediately in the cloud and there is no need to push configuration to terminals.
Transaction Monitoring
Along with detecting field issues, another important requirement in the market is monitoring transactions to know and follow transaction and user behavior trends. For example, suddenly increasing the number of PIN entry bypass cases might show that some EMV parameters are incorrectly configured causing lots of transaction declines. With the increasing COVID cases, most acquirers want transactions to be performed without an online PIN, so it is very crucial to monitor particularly this case.
Kernel-in-the-Cloud goes far beyond EMV for monitoring of transactions thanks to the detailed transaction data generated by the L2 kernel. For example, today EMV data elements in the authorization message show offline data authentication has failed but doesn’t indicate the reason for this situation. Kernel-in-the-Cloud indicates the root cause of the authentication failure, such as missing Public Key, expired card certificate, or missing card data.
Another difficulty for monitoring and reporting EMV transactions today is each contactless L2 kernel has different data elements to show certain situations. For example, let’s consider that we want to understand the cardholder verification method in a transaction that might be an online PIN, signature, consumer device verification, or No CVM. Visa, MasterCard, and other contactless L2 kernels have different data elements to indicate this situation. For acquirers, POS vendors, and other parties who want to monitor transactions, it is very difficult to develop an inquiry to get to know this situation. Kernel-in-the-Cloud uses unified data elements to show these kinds of transaction information, which makes it very easy to develop inquiries, to monitor and report transactions. These unified data elements, developed by Fairbit, logs detailed transaction information as unified across all contact and contactless L2 kernels. These data elements are stored in the cloud database and used for monitoring and reporting.
In the competitive market today, analyzing and quickly fixing field issues has become more important than ever. This would give significant competitive advantages to the POS vendors, ISOs, ISVs, acquirers, and other solution providers. Merchant satisfaction being one of the highest priorities, the most important thing is to become aware of the issues instantly and have a fix in a very short time. The kernel-in-the-Cloud solution is a solution that helps to facilitate addressing these field issues in an efficient way.
