Return of NFC: Curse of the secure element

by Cherian Abraham 8 min read March 13, 2013

This post is in response to the recent Bankinter story of NFC payments at the point-of-sale without requiring SE – and the lack of any real detail around how it plans to achieve that goal. I am not privy to Bankinter’s plan to dis-intermediate the SE, but as I know a wee bit about how NFC works, I thought a post would help in clearing up any ambiguity as to how Card emulation and Host Card emulation differs, upsides, challenges – the whole lot.

Back in December of 2012, Verizon responded to an FCC complaint over its continued blocking of GoogleWallet on Verizon network. The gist of Verizon’s response was that as GoogleWallet is different to PayPal, Square and other wallet aggregators in that its reliance on the phone’s Secure Element – a piece of proprietary hardware, lies behind the reason for Verizon denying GoogleWallet from operating on its devices or network. Verizon continued to write that Google is free to offer a modified version of GoogleWallet that does not require integration with the Secure Element.

Now Software Card Emulation was not born out of that gridlock. It had been always supported by both NXP and Broadcom chipsets at the driver level. Among operating systems, BlackberryOS supports it by default. With Android however, application support did not manifest despite interest from the developer community. Google chose to omit exposing this capability via the API from Android 2.3.4 – may have to do with opting to focus its developer efforts elsewhere, or may have been due to carrier intervention. What very few knew is that a startup called SimplyTapp had already been toiling away at turning the switch back on – since late 2011.

Host Card What?

But first – let’s talk a bit about Card Emulation and how Host Card Emulation (or SE on the Cloud) differs in their approach. In the case of GoogleWallet, Card Emulation represents routing communication from an external contactless terminal reader directly to the embedded secure element, dis-allowing visibility by the operating system completely. Only the secure element and the NFC controller are involved. Card Emulation is supported by all merchant contactless terminals and in this mode, the phone appears to the reader as a contactless smart card. Google Wallet, Isis and other NFC mobile wallets rely on card emulation to transfer payment credentials to the PoS. However the downsides to this are payment apps are limited to the SE capacity (72kb on the original embedded SE on Nexus S), SE access is slower, and provisioning credentials to the SE is a complex, brittle process involving multiple TSM’s, multiple Carriers (in the case of Isis) and multiple SE types and handsets.

Host Card Emulation (or Software Card Emulation) differs from this such that instead of routing communications received by the NFC controller to the secure element, it delivers them to the NFC service manager – allowing the commands to be processed by applications installed on the phone. With that, the approach allows to break dependency on the secure element by having credentials stored anywhere – in the application memory, in the trusted execution environment (TEE) or on the cloud.

The benefits are apparent and a couple is noted:

  • NFC returns to being a communication standard, enabling any wallet to use it to communicate to a PoS – without having to get mired down in contracts with Issuers, Carriers and TSMs.
  • No more complex SE cards provisioning to worry about
  • Multiple NFC payment wallets can be on the phone without worrying about SE storage size or compartmentalizing.
  • No need to pay the piper – in this case, the Carrier for Over-the-air SE provisioning and lifecycle management. Card Issuers would be ecstatic.

However this is no panacea, as software card emulation is not exposed to applications by Android and host card emulation patches that have been submitted (by SimplyTapp) have not yet been merged with the main android branch – and therefore not available to you and I – unless we root our phones.

Which is where SimplyTapp comes in.

SimplyTapp appealed to an early segment of Android enthusiasts who abhorred having been told as to what functionality they are allowed to enable on their phones – by Google, Carriers or anyone else. And to any who dared to root an NFC phone (supported by CyanogenMod) and install the Cyanogenmod firmware, they were rewarded by being able to use both SimplyTapp as well as GoogleWallet to pay via NFC – the former where credentials were stored on the cloud and the latter – within the embedded SE.

So how does this work? SimplyTapp created a Host Card Emulation patch which resolves potential conflicts that could arise from having two competing applications (SimplyTapp and GW) that has registered for the same NFC event from the contactless external reader. It does so by ensuring that upon receiving the event – if the SimplyTapp app is open in the foreground (On-Screen) then the communication is routed to it and if not – it gets routed to GoogleWallet. This allows consumers to use both apps harmoniously on the same phone (take that ISIS and Google Wallet!). SimplyTapp today works on any NFC phone supported by CyanogenMod. Apart from SimplyTapp, InsideSecure is working on a similar initiative as reported here.

You get a wallet! And you get a wallet! Everyone gets a wallet!

Well not quite. What are the downsides to this approach? Well for one – if you wish to scale beyond the enthusiasts, you need Google, the platform owner to step up and make it available to all without having to root our phones. For that to happen it must update the NFC service manager to expose Host Card emulation for the NXP and Broadcom chipsets. And if Google is not onboard with the idea, then you need to find an OEM, a Handset manufacturer or an Amazon ready to distribute your amended libraries. Further, you can also expect Carriers to fight this move as it finds its investment and control around the secure element threatened. With the marked clout they enjoy with the OEM’s and Handset manufacturers by way of subsidies, they can influence the outcome.

Some wonder how is it that BlackberryOS continues to support Host Card Emulation without Carrier intervention. The short answer may be that it is such a marginal player these days that this was overlooked or ignored.

The limitations do not stop there. The process of using any cloud based credentials in an EMV or contactless transaction has not been certified yet. There is obviously interest and it probably will happen at some point – but nothing yet. Debit cards may come first – owing to the ease in certification. Further, Closed loop cards may probably be ahead of the curve compared to Open loop cards. More about that later. *Update: Latency is another issue when the credentials are stored on the cloud. Especially when NFC payments were called out last year to be not quick enough for transit.*

So for all those who pine for the death of secure elements, but swear fealty to NFC, there is hope. But don’t set your alarm yet.

So what will Google do?

Let’s consider for a moment that Google is down with this. If so, does that represent a fork in the road for Google Wallet? Will the wallet application leverage HCE on phones with inaccessible Secure Elements, while defaulting to the Secure Element on phones it has? If so, it risks confusing consumers. Further – enabling HCE lets other wallets to adopt the same route. It will break dependency with the secure element, but so shall it open the flood gates to all other wallets who now wants to play. It would seem like a pyrrhic victory for Google. All those who despised proximity payments (I am looking at you Paypal & Square!) will see their road to contactless clear and come calling. As the platform owner – Google will have no choice but to grin and bear it. But on a positive note, this will further level the playing field for all wallets and put the case for contactless back – front and center. Will Google let this happen? Those who look at Google’s history of tight fisted control over the embedded SE are bound to cite precedent and stay cynical.

But when it comes down it, I believe Google will do the right thing for the broader android community. Even on the aspect of not relinquishing control over the embedded SE in the devices it issued, Google had put the interests of consumer first. And it felt that, after all things considered it felt it was not ready to allow wanton and unfettered access to the SE. Google had at one point was even talking about allowing developers write their own “card emulation” applets and download them to the SE.

Broadcom also has an upcoming quad-combo chip BCM43341 that has managed to wrap NFC, Bluetooth 4.0, Wi-Fi and FM Radio, all on a single die. Further, the BCM43341 also supports multiple Secure Elements. Now, I also hear Broadcom happens to be a major chip supplier to a fruit company.

What do you think?

This is content was originally posted to Cherian's personal blog at DropLabs.

Related Posts

How Consumer Vehicle Choices Are Shaping Automotive Loan Trends

Conversations about rising auto loan balances and higher monthly payments has often centered around increasing vehicle prices and elevated interest rates; and while those factors have undoubtedly played a role, another important piece of the puzzle is the type of vehicles consumers are choosing to purchase. According to Experian’s Automotive Consumer Trends Report: Q1 2026, consumers are continuing to opt for SUVs over other vehicle types, a trend that may be contributing to higher average loan amounts and monthly payments. SUVs accounted for 63.5% of all new retail vehicle registrations over the last 12 months, up from 62.8% a year ago. Additionally, more than 117 million SUVs were in operation across the United States in the first quarter of 2026, making up 42.2% of the market share. At the same time, traditional passenger cars continue to fall in share, coming in at 16.5%, a decrease from 18.4% last year. As consumers increasingly gravitate towards the larger vehicle segment, it reflects the ongoing desire for versatility, cargo capacity, and family-friendly functionality. Electrification’s growing role in consumer purchasing behavior Interestingly, electrified SUVs continue to gain traction, representing 27.7% of all new SUV registrations, these vehicles include battery-electric, hybrids, plug-in hybrids, and other alternative fuel types. Diving a bit deeper, the Tesla Model Y was the market share leader for new, retail electrified SUV registrations in the last 12 months, coming in at 15.8%. Rounding out the top five were Honda CR-V (9.6%), Toyota RAV4 (7.2%), Chevrolet Trax (7.2%), and Toyota Grand Highlander (3.4%). As model availability and familiarity with the electrification segment grows, the broader adoption of these vehicles are playing an increasingly important role in vehicle pricing and overall consumer demand. While average loan amounts and monthly payments are being driven by a combination of factors such as financing costs and consumer purchasing behavior, data in Q1 2026 demonstrates the continued interest in SUVs. This suggests that the industry’s shift toward larger vehicles is likely playing a meaningful role in today’s financing environment. To learn more about SUV insights, view the full Automotive Consumer Trends Report: Q1 2026 presentation.

Published: June 17, 2026 by Kirsten Von Busch
When New Data Impacts MBS Pricing: Student Loan Debt

In our previous post, we described the Current Second Lien Balance field, which is one of over 2,000 fields in the new Experian Mortgage Loan Performance (MLP) dataset. We showed that the Current Second Lien Balance field meets our three-pronged materiality standard for new data delivery: New: Provides information not available in existing datasets (i.e., orthogonal to currently available data). Material: Impacts a sizeable portion of the MBS universe. Significant: Differentiates collateral performance by a large enough margin to influence trading and risk management decisions. In this article, we discuss another field that satisfies the above criteria: Student Loan Balance.  We evaluate this field in the context of these criteria. First, however, we provide a summary of the MLP dataset and how it compares to standard GSE loan-level data available today. Standard GSE Data vs. Experian Mortgage Loan Performance (MLP) Data The MLP dataset contains thousands of fields describing mortgage performance from each borrower, loan, and property perspective, all refreshed monthly (including, amongst other things, new credit scores and refinance inquiry activity, loan performance, filed junior liens, and AVM values).  MLP differs from loan-level data provided byFreddie Mac, Fannie Mae, and Ginnie Mae, which the vast majority of market participants solely rely on, in a number of ways: Standard data provided by the GSEs and GNMA does not contain all the information necessary for accurate forecasting of mortgage prepayment and credit performance. Basic, critical fields like borrower’s current credit score and current junior liens on the property are missing. The new Mortgage Loan Performance (MLP) dataset from Experian contains borrower, loan, and property data fields covering the entire mortgage universe, including Agency, Non-Agency, and Esoteric mortgage products (CES, HELOC, Reverse), both securitized and non-securitized. MLP enables full three-dimensional (borrower + loan + property) tracking with persistent keys for borrower (before and after refinancing), loan (in securities/deals even after exit due to payoffs or buyouts, including before and after MSR sales), and property.  This enables end-to-end analysis of each borrower’s (and property’s) mortgage experience throughout their credit lifecycle. New, Material and Significant Field:  Student Loan Debt MLP contains a number of fields describing each mortgage borrower’s student debt load, including amounts in repayment, forbearance and collections; estimated interest rate, time remaining until forbearance expiration, and more. In the interest of simplicity, for this article we’ll focus on a single student loan-related field within MLP: Student Loans Balance, which is defined as the total balance on open non-deferred student trades reported in the last 3 months. Is Information Regarding Student Loans New to Markets? Standard loan-level data disclosed by the GSEs and GNMA contain no student-loan-specific fields. Theoretically, fields related to DTI at origination might capture some aspect of student loan debt. So, in the best case scenario for an investor relying solely on standard disclosure, a DTI value as of origination is provided -- yet is never updated as the loan seasons and the borrower’s debt and income change (see more here).  But in the case of federal student loan debt attached to mortgages originated from early 2020 to late 2023, the level of detail provided by disclosure may be even more unknown due to COVID-era repayment and reporting moratoriums. The student loan repayment moratorium was a temporary federal policy that paused required payments, set interest rates to 0%, and suspended collections on most federally-held student loans. The moratorium began in March 2020, with payments resuming in October 2023, making it approximately 3.5 years in duration—the longest consumer credit payment pause in U.S. history. (Source: NCUA ) During the moratorium, student loan-related debt loads may have been understated as federal loans were in a temporary state of $0 repayment.  As an alternative to leaving student loan debt completely out of DTI calculations, an imputed payment equal to only 0.50% of the outstanding balance was often used as a placeholder for a borrower’s DTI calculation. As a result, mortgages originated during the moratorium may have artificially low reported DTIs for borrowers with student loan debt, materially understating true post-moratorium debt .  Accordingly, prepayment risk for these loans is likely overstated in mainstream market models. Standard data only reports information related to the primary mortgage and does not include any details on the borrower’s other debts with the exception of DTI at origination, which is never updated throughout the life of the loan. In contrast, MLP provides a comprehensive view of the borrower’s full credit profile, including other obligations such as credit cards, mortgages on other properties, student loan balances, and much more. Is Student Loan debt material to the residential mortgage market? Approximately $11 trillion of residential mortgage loans were originated during the student loan payment moratorium (Source: Experian MLP Dataset), a period marked by historically low mortgage rates during the COVID era.  As discussed above, DTI data contained in standard market disclosure may be particularly inaccurate for these loans. As the Wall Street Journal recently reported, a new report from the Federal Reserve of New York shows a rise in student loan default rates by age group.  Student l Of today’s $13 trillion in outstanding mortgage debt, more than 10% of that debt ($1.5 trillion) is associated with borrowers who carry student loan debt.  For these borrowers, the average amount of student loan debt outstanding is approximately $50,000, versus a mortgage balance of approximately ~$289,000. In other words, the average student loan debt balance is almost 20% of the mortgage balance for the average borrower who carries both. For this set of borrowers, the average monthly payment is approximately $400 for student loan vs. approximately $2,200 for 1st lien mortgage—so that monthly student loan payments are a significant debt load, approximately 20% of the monthly mortgage payment.  (Source:  Experian MLP Dataset) Is the effect of student loan debt a significant driver of performance? Figure 1 illustrates prepayments by student loan balance for a sample of loans drawn from MLP. The chart illustrates that borrowers with larger student loan balances prepay much more slowly, likely because some are effectively locked out of refinancing once student loan payments resume due to elevated DTI. The debt-to-income (DTI) ratio calculated using actual student loan payments may be significantly higher than the DTI calculated during the moratorium, in some cases exceeding GSE eligibility thresholds. As illustrated in Figure 1, for in-the-money (ITM) collateral, the differential between loans with material student loan balances (greater than $200,000) and loans with no student debt can reach up to 5 CPR. Notably, even for out-of-the-money (OTM) collateral, loans with student debt prepay 1 to 3 CPR slower, likely reflecting reduced mobility due to tighter financing constraints when purchasing a new home. Pools with otherwise similar prepayment characteristics may exhibit different prepayment behavior depending on the distribution of student loan exposure within their collateral. In addition, because loans with student debt tend to prepay more slowly, this effect increases over time due to burnout: loans without student debt prepay and exit the pools more quickly, leaving a higher concentration of slower-paying loans behind.  Given that 10% of the $13 trillion outstanding mortgage market is associated with borrowers who have student loans (Source:  Experian MLP dataset)—and that student loans have a meaningful impact on prepayments—many pools issued between March 2020 and October 2023 may be subject to this student loan debt CPR throttle, and therefore mispriced by investors relying exclusively on standard market data. Fig 1. Prepayment S-Curve: Student Loans Balance Source:  Experian MLP dataset hosted on IVolatility Data-Driven Platform   _____________________________________________________ Michael Pyatski advises MBS traders, portfolio managers, quants, risk managers, loan originators, and technology professionals on making informed, data-driven business decisions that drive revenue growth, enhance risk management, and reduce trading costs. With more than 15 years of experience as an Agency RMBS trader—including serving as Head of the Proprietary Trading Desk at BNP Paribas—Michael developed and successfully implemented relative-value, data-driven profitable trading strategies to capture market opportunities embedded in data but not fully priced by the market. His trading experience, combined with a Ph.D. in econometrics, led him to found the Data-Driven Portal (https://datadrivenportal.com/), a platform that provides advanced technology for MBS trading and risk management. The platform’s No-Model Data-Driven technology leverages big data, econometric analysis, and AI to help traders identify relative-value opportunities in RMBS markets and generate above-market, risk-adjusted returns. _____________________________________________________

Published: June 17, 2026 by Perry DeFelice
Empowering merchants to reduce first-party fraud and chargebacks

Reduce first-party fraud and chargebacks with data-driven strategies that help merchants prevent disputes, protect revenue and improve customer trust.

Published: June 15, 2026 by Charles Hunter