Gain exclusive insights into the evolving world of payments that are reshaping the banking sector and enhancing customer experiences.

Thought Leadership

Recently Apple announced “Apple Card” as a credit card designed to be used with Apple Pay on Apple devices. Obviously, this is a very interesting topic for banks and issuers and the announcement raised several questions on how the product works, what the technology behind it is and if Apple is now becoming a bank.

In the 24 hours after the announcement, we did our research to answer the top 10 questions that have been raised on this topic. We intend to update this blog post as we learn more and as more information becomes available.

Apple Card is a Mastercard credit card digitally held in the Apple Wallet. It will be supplemented by a physical Mastercard titanium card with an EMV chip for card acceptance environments without any support of contactless (NFC) technology at the POS (where Apple Pay can not be used).

Based on our current interpretation, the Apple Card offering contains different (virtual) card numbers and tokens to serve all payment use cases:

Due to the fact that all generated tokens are linked to the virtual card number and all card numbers are linked to a single payment account at Goldman Sachs, this set-up enables a holistic view on all transactions and enables the announced features around flexible payment plans and dashboards of spendings for cardholders.

It is not possible to know the exact set-up at this point in time but here is what we gathered from a screenshot of the ad video:

67df10a7-ad2d-4827-94c4-0fcecb3c8967_738x517.jpeg

Our interpretation of account and cards set-up

Like other Apple products, they focus on simplicity and user experience. Apple Card is different from other credit cards in a way that it is a “digital first” card, with a strong focus on digital payments and tokenization technology behind it. The titanium physical card only comes as a fallback solution wherever Apple Pay is not available.

Apple Card comes with some interesting features such as easy onboarding, analysis of spending as well as an estimation of the interest to be paid by the cardholder (US specific).

We think one of the cool features of Apple Card is the real-time fraud protection that notifies a cardholder about suspicious transactions and ask for feedback on the flagged transaction.

04db6fdf-bb66-4754-bb7a-f362206aaeca_250x369.jpeg

Additionally, by using machine learning, Apple will translate confusing merchant names and codes into meaningful insight so that the cardholder can recognize the merchant and the transaction. We have to admit that while this is a very useful feature, it is not totally new and some challenger banks like Monzo or fintechs like Contovista are also already doing it.

No, Apple decided to partner up with Goldman Sachs bank in the USA to issue Apple Card. This business model is widespread in the payments market (often used by retailers and airlines) and usually called “co-branding”. The entity issuing the card (means holding the Mastercard license, holding the regulatory required licenses, maintaining the payment account and being the contractual partner of the cardholder) is Goldman Sachs only. Apple is used as a sales channel, a technology provider and as a pass-through wallet provider (Apple Pay) but is never involved in the transaction process and/or the flow of funds.

4. Is there revolutionary technology behind?

No, all the features used by Apple and Goldman Sachs already existed in the market but Apple obviously did a very good job puzzling together and leveraging technology of Mastercard and other solutions available in the market.

Backbone of the product is Mastercard Digital Enablement Service (MDES) to allow the card issuer Goldman Sachs to tokenize a card number and therefore “multiply” a single card number to many tokenized card numbers.

Not printing the card number and the CVC2 on a physical card but to show them only in the Apple Wallet App is as well nothing new and already in use with several card issuers offering so called “virtual cards”.

So far the product is announced by Goldman Sachs and Apple for the US market (and US cardholders) only. Due to the fact that card issuing is subject to corresponding licenses in most markets, globally it will be interesting to watch if Goldman Sachs will work on a global roll-out or if Apple is going to partner with other banks/payment institutions for markets outside the US.

In addition, it seems like it is a premium product, not only because of the card being made from titanium, but also it seems like Apple has quite tight credit score checking and they are targeting the high-end customer category. Most likely iPhone users who can afford to spend way over 1000 USD for an iPhone XS with fall into the eligible category ;-)

Apple Card will be available this summer in the US. It seems that the whole solution is tightly integrated with the processing platform and operations of Goldman Sachs. Therefore, we think that it won’t be easy to bring the same setup to other countries soon (e.g. the US payment market works on a single message system, the european market on a dual message system). In the announcement, it was mentioned that Goldman Sachs was a good choice since they were mainly an investment bank with a very limited retail customer base (recently launched Goldman Sachs digital retail bank “Marcus:”). Therefore, the partnership can be seen as a win-win for Goldman Sachs and Apple. However, it is unlikely to be a winning case for banks with existing retail customers.

 as an indication, which was launched in partnership with the Green Dot Corporation as a US-only product in late 2017, there is no solid information if an when this product will be available in other countries.

7. How does this all relate to Apple Pay Cash card?

The Apple Pay Cash card, a virtual prepaid card issued in partnership with the Green Dot Corporation, was introduced in late 2017 in order to bring Peer-2-Peer (P2P) payment to Apple Pay.

Now with the announcement of Apple Card, people might ask how Apple Card is then different from the already available Apple Pay Cash card. The main difference is that Apple Card is an actual credit card while Cash card is a prepaid card mainly used to store money received via P2P payments. The two products will coexist and the way they work together is that the (1%-3%) cashback reward that cardholders get by using Apple Card will be credited to Apple Pay Cash card and can be spent wherever Apple Pay is accepted (in-store as well as online). Also the Cash card is still used to send and receive money via iMessage.

Considering Apple’s attention to detail and focus on simplicity, this coexistence is an unusual compromises and certainly not a great user experience. However the Cash card allows Apple to offer P2P payments all US customers, regardless of their banks support for Apple Pay. Also it allows them to implement P2P without having to rely on the P2P rails from Mastercard and Visa (‘MoneySend’ and ‘Direct’). Probably these strategic values were more important than the very best user experience. With Apple Card being available soon, it is to be seen if these two products will be merged into one at some point down the road.

For the physical titanium card Apple made some interesting decisions. The card only shows the logo of Apple, Mastercard and Goldmann Sachs. No card number, no magnetic stripe, no expiration date, no CVC security code and no signature. Which means the card itself can only be used with the Chip and PIN at the POS. The card number, expiration date and the CVC will be displayed in the Apple Wallet App. We assume however that a CVC is only available for the virtual Apple Card number and not the card number that is personalized onto the chip of the physical card. By limiting the physical card to POS transactions, the fraud exposure is very low. This means that with the exception of loss and damage, there is no reason to replace the card, which makes sense considering the cost of the blank card made from titanium and the announcement that there will be no annual fee for the card.

07cb446b-1d48-40bc-a6cf-6176cd440023_800x280.jpeg

Also the card doesn’t support contactless payments (NFC). One might assume they removed the NFC interface because cards made from metal can pose an extra challenge. Also it is possible that they have done it in order to prevent against extracting the card number via NFC, if the card is lost or stolen. However it’s way more likely that this was a deliberate decision to trigger the cardholder to use Apple Pay whenever contactless payment is available. Also the fact that for payments with the physical card there is only 1% cashback (instead of 2–3% with the virtual Apple Card) points to this direction.

While all of this together is a fresh approach, it’s actually mainly about removing features from the physical card combined with great marketing to highlight the security advantages that come along with it.

With regard to privacy, according to the information released by Apple, Apple claims that they don’t have access to transaction data and that the data is only stored on your iPhone. However, of course Goldman Sachs as the issuer will use the data to operate the Apple Card.

Limiting the physical card to an EMV Chip only card can still cause acceptance issues, especially in markets where not yet all merchant POS terminals are EMV capable and magnetic stripe technology is still in use. Moreover, not embossing the card number and cardholder name could limit the usage of the card in certain niche-acceptance environments like for example car rental where a lot of merchants still work with embossed card data.

The physical card also does not include contactless technology because obviously for contactless transactions the iPhone with Apple Pay technology is intended to be used. Even though this means a cardholder should always carry his mobile phone, going to a shopping trip with the physical card only is probably not a good idea.

So far, Apple and Goldman Sachs did not talk about a PIN but for the physical EMV card there will be a PIN (most likely an online and an offline PIN) for transactions at POS terminals and ATMs. The PIN and the PIN handling is expected to work like for all other cards in the market (PIN generated by Goldman Sachs and sent to the cardholder). The EMV technology and security framework does not allow for a lot of fancy features, which means an Apple Card cardholder still has to remember his PIN when using the physical card. But of course Apple can choose to also provide an option to reveal the PIN in the Wallet App, like some challenger banks do it already.

10. Is Apple Card a threat or attack on banks?

We think that the partnership with a big incumbent (Goldman Sachs) is a clear signal that Apple still believes in traditional financial institutions. Considering that the financial market is a highly regulated domain (with all KYC, anti-money laundry, cross border etc), we think that being a bank would slow down Apple and therefore is not very attractive for Apple. And if Apple really wants to be a bank, they can simply buy one. Therefore, we believe that it was a deliberate decision by Apple to focus on facilitating payments by going into a “co-branding” agreement with Goldman Sachs.

Apple’s move to the payment domain is an obvious attempt to lock in customers even tighter in the Apple ecosystem and can be seen as a great example of how a company can be a relevant player in the financial industry and win the customer interface without actually being a regulated bank.

On Apple Card web page, Apple is teasing banks by saying “When you want to see how much you’re spending, there’s no need to log in to a separate website or app”. We see this as a wake up call to financial institutions to start providing similar features in order to not become ‘dumb ledgers’, which is a similar threat to what the telecom operators are still facing to not become ‘dumb pipes’.

With Apple Pay and now Apple Card, Apple is actually entering into the payment channels. The features Apple Card is offering are very comparable to those of challenger banks, such as Monzo, Revolut and N26. Therefore, in the sense of attacking banks, Apple Card might affect challengers even more than the incumbents. Nevertheless, Apple’s move also clearly shows that the challenger banks followed the right path by first launching a payment product with interesting features and simple on-boarding and then evolving from there.

Regardless of whether Apple is now a threat to banks or not, we don’t believe that Apple has the intention to become a bank in the near future.

We hope that we have answered some of your questions in this blog post. Please share your thoughts and insights with us and if you found this post helpful, please share it with those who might also be interested in this topic.

Don't miss out on our exclusive content! Subscribe today and stay ahead of the curve 🚀

Recently Apple announced “Apple Card” as a credit card designed to be used with Apple Pay on Apple devices. Obviously, this is a very…

Apple Card Uncovered-Top 10 Q&A

A few months have passed since the EMVCo. Secure Remote Commerce specification was published and yet if you search the topic on the internet, it is hard to find an article that simply explains the key takeaways for banks or issuers. First of all, not everyone has the time or interests to read a technical specification. Second, even if you do have interest and time, the EMVCo. specifications only describes a framework for SRC and therefore, it is too generic to draw any conclusion on roles and responsibilities in the SRC ecosystem. Therefore, everyone is waiting for the payment schemes to publish their specifications and shed light on this topic.

While waiting for the schemes to get a clear direction is an option, we were too impatient to wait and decided to do our own research to find answers to questions we had or got from people asking. In this article, we would like to share with you our understanding of SRC specification and our reflections on 7 top questions that every issuer or bank might ask about SRC.

Disclaimer: The views and opinions expressed in this article are solely ours and do not necessarily express the views or opinions of any official body, such as EMVCo. or the payment schemes.

1) What is SRC exactly and why should I care?

Secure Remote Commerce is all about online shopping, so-called online-payments, eCommerce, mCommerce, digital commerce, Web-based payment, etc. According to the specification, the framework is focused on card payments and is aimed at:

Looking at these two main aims, it is clear why issuers should care about SRC and why they should know about the impacts for them. Are you curious now? Just continue reading!

The picture below shows a high-level overview of SRC participants based on the EMVCo. specification:

a726bee4-d6e3-446a-a697-a6a279f43969_800x378.jpg

EVMCo. defines the followings 6 roles in the SRC ecosystem:

As you can see, most of the roles in the SRC ecosystem are rather straightforward. For instance, SRC I and DSA can be covered by PSPs and merchants. The SRC System role can be fulfilled by the payment schemes (e.g, Mastercard and Visa) and SRC PI will be fulfilled by issuers. The only role that remains rather open, is the role of DCF. While payment schemes wallets, such as masterpass and Visa Checkout, could fulfil this role, the question is if the role is open to other participants and if so, what are the other potential participants for such a role?

The most important role issuers have is to enable cardholders for SRC payments by enrolling their Payment Cards into SRC system. The enrollment process requires that issuers define the following parameters on the SRC system:

It looks like that issuers have to define almost the same parameters as when they enable tokenization for their BIN Ranges. This indicates that the path to SRC would be rather straightforward for issuers, who:

The list of parameters to be defined by issuers also shows that issuers have full control over if and how their cards can be used in SRC transactions.

4) How might the customer journey look like?

There is not yet a definite view on how the customer journey would look like, and there will be different flows, depending on if the customer is registered for SRC and if a merchant remembers the customer. However, the EMVCo. specification has defined some UI guidelines for customer recognition. In the picture below, you can see an example user experience for a customer that has been registered by the issuer for SRC:

bee0ee55-6e96-4c0e-8ab1-2bdf5a686817_800x308.jpeg

As mentioned, this is an example of UX and some steps could be performed differently or skipped altogether. For example, based on the transaction risk parameters, an issuer may decide to authorize the payment without additional cardholder authentication (the last step).

Another important point is that the list of registered cards and the shipping address are provided by DCFs. Our speculation is that wallets such as masterpass can be an example of a DCF that provides the cards available in the masterpass wallet for the identified cardholder.

6) Where do 3-D Secure 2.0 and Tokenization fit in?

EMVCo. specification only explains that these two technologies can be used as part of the SRC program. However, the how and where is not specified and needs to be clarified by the specific SRC programs from the different payment schemes.

Our understanding of this question, based on the EMVCo. specification is as follows:

When a cardholder is registered for SRC, the SRC system creates a profile that contains information about the contact information, cards and devices related to the cardholder.

One of the information stored in the cardholder profile is ‘PAN Reference Information’ for each registered PAN (Primary Account Number). Once a PAN is registered in the SRC system, the SRC system creates and shares a Reference Number with related DCFs and merchants (DSA & SRC I) to be used for future communication with the SRC system. This is to ensure that the PAN is not stored by any party and instead the ‘Reference Number’ is used in communication between the systems. This is where the existing tokenization systems (e.g. MDES, VTS) can be used to create tokens or so-called PAN Reference Numbers. Based on this, we assume that the schemes’ SRC system is a part or very close to their existing tokenization systems.

As you have seen in the customer experience flow, there will be parts where cardholder has to verify his identity to access his profile and/or authenticate to complete an SRC transaction. This is where we think the existing the 3-D Secure technology will play a role.

4) How is SRC different from W3C Web Payments?

If you have been following web payment developments, you must have heard about W3C Web Payments group. The purpose of the Web Payments Group is to make online payments simpler and more secure. As a part of this goal, they have defined a set of standards, among which are Payment Request API and Payment Handler API. Discussing the details of each of these standards are beyond the scope of this article. But for those you who are familiar with Payment Request API, one might say ‘wait a second!’. Payment Request API is also aimed to address the fragmentation of checkout solution and improve the user experience. So how is SRC different from the Payment Request API? Fair question! We have tried to describe the differences in the table below:

bbc3b23d-feb8-4721-bf3c-7d2afb641595_800x669.png

Payment Request API vs. Secure Remote Commerce

Now you might be probably asking yourself, aren’t these two standards somehow complementary? And the answer is ‘yes’! Indeed, the SRC and Web Payment Standards can work well together. However, it’s very much up to the payment schemes how they are going to use the Payment Request API or other standards from W3C Web Payments when defining their requirements and implementation mandates for SRC. You can read a more detailed analysis on this topic here.

7) In the end, will it be ‘ONE’ checkout button?

The EMVCo. specification does not mandate any specific implementation about the checkout button, neither any mandates regarding the cardholder identifier. Therefore, it is up to the SRC systems and SRC Programs (aka, payment schemes) to decide if there will be a common button or if each SRC Program will have their own specific checkout button. If we think of solving the fragmentation and enhancing the customer experience, we would assume that ‘One Checkout’ button would be a better choice for customer experience, but we are not the one who decide ;-)

Whether or not the SRC framework can solve the fragmentation issue or not, depends on how the program will be specified by the schemes and who could participate as the DCF in this ecosystem. Nevertheless, we are hopeful that SRC program paves the path for ‘token on file’ so that merchants can manage payment data in a more secure and streamlined way.

An important question to be answered is, if and how the SRC programs will include the Payment Request API in their implementations. So far, public information from W3C Web Payments group shows that only little analysis has been done on whether and how the SRC framework and Web Payment standards can work together. We hope that in the next step of refining the SRC specification and defining schemes’ specific implementation mandates, EMVCo., payment schemes and W3C get together to create complementary solutions that at the end improve the customer experience.

A few months have passed since the EMVCo.

Blog

Apple Card Uncovered-Top 10 Q&A

7 Things Every Issuer And Bank Should Know About The Secure Remote Commerce (SRC)