2. Mobile Wallets
Tackling the multi-wallet problem to achieve mass market adoption of contactless payment services

3. A Quick Introduction
Neal Michie - Technical Business Development Director at Helixion
Background in software engineering before falling into Business Development role
Helixion works with both network operators and service providers to deploy secure contactless transaction products.
Why I’m qualified to talk on this subject?

4. Agenda Understanding the different wallet architecture options.
What is the multi-wallet problem and what it means for service providers.
How to address the multi-wallet problem.
Seems to be an issue that more-and-more people as releasing will cause problems – e.g.GSMA
Multi-wallet problem is certainly something our customer’s our talking about; and potential customers using as a reason not to progress project.
When scoping presentation was only going to cover technical issues but when investigating discovered that it was only a small part of the problem
An ambitious range of subjects to cover in 30 minutes.

5. Wallet architectures
First thing, lets understand a wee bit about mobile wallets.

6. The mobile wallet “Wallet” means everything to everyone.
For this presentation a mobile “wallet” is simply a container for services.
First problem – one of terminology.
Wallet term used to describe an NFC payment app, a P2P payment app, a cloud based loyalty app, smart ticketing app….
If a leather wallet contains some money; a whole host of cards from credit cards, loyalty cards, tickets; receipts, maybe even photos of loved ones… is it too make a jump to say that mobile wallet is exactly the same – a container of third party services.

7. Wallet types
Container wallet, widget wallet? – Unfortunately it’s not quite as neat as that.
At the very least need to think of wallets as a sliding scale – even then that’s a simplification.
Sliding scale starts with thin wallets (basically the phone is the wallet and there is no wallet UI) to thick wallets (wallet is an app and service providers gets no or little control over user experience)
In between there’s container wallets, template wallets, etc)
First challenge for a service provider is getting the user experience they want in someone else’s wallet – what if they want to embedded payment within their mobile banking app.
Control moves from Service Provider to Wallet Provider

8. Wallet types – thin - “phone as a wallet”
Wallet functionality embedded deep into the phone.
No visible wallet icon on phone’s launcher.
Each service appears to the user an it’s own application – because it is it’s own application.
As Service Provider applications are native applications, it is flexible and can take advantage of all handset functionality.

9. Wallet types – thick - “monolithic wallet”
Wallet functionality is provided as an app on the phone.
Wallet also provides service functionality.
Service provider simply provides branding information to the wallet provider.

10. Wallet types – middle ground - “widget wallet”
Most likely the wallet will be somewhere in the middle of the two extremes.
Wallet functionality is provided as an app on the phone.
Service provides create “widgets” that run within the wallet application.
“Widgets” typically created in platform independent code (e.g. JME, HTML).
“Widgets” typically light weight and can only use functionality exposed by wallet.

11. Multi-wallet problem

12. The multi-wallet problem
Let’s make an assumption that the service provider isn’t the wallet provider. The wallet provider will almost certainly be the secure element owner (given the current market that’s a network operator).
Separate commercial arrangements for each wallet.
So now the service provider has multiple wallets to integrate into. It’s almost certain each one will be different.
I said it the sliding scale was a simplification. Even if the service provider is likely enough to have to deal with wallets at the same point on the sliding scale, they’ll be able to create a similar user experience for each wallet but still have multiple integrations to go through.

13. Independent solutions
We said each wallet is different and so each wallet requires its own solution.
Recreating solution of each wallet is expensive.
Recreating solution of each wallet takes time.

14. Weakened branding
Depending where a wallet sits on our sliding scale, the ability to create the desired user experience changes.
Thick wallets limit scope for defining service provider user experience.
Balancing act between:
Defining a user experience to the lowest common dominator.
Having different user experiences on each wallet deployment.
A really thick wallet will give no control over defining the experience.
Different experiences mean: more effort in customer care, some customers feeling alienated because they are missing out. It’s the service providers brand that is visible, does the average customer release the limitations come from the wallet?
What we’ve sign in the market is wallet providers trying to control or limit user experience.
If I’m a bank, I’d be asking myself: why should a customer’s choice of mobile network operator define their banking experience? For the banks the answer is “it shouldn’t” – and control imposed by network operators is reducing service providers appetite for deploying services.

15. Solving the multi-wallet problem (technical)

16. Requirements of a solution
Provide an efficient (low cost / low effort) route to reach ALL customers.
To protect their brand by providing a consistent user experience to the customer.
Give Service Providers control over the user experience.

17. A Solution
Solution is to architect solutions that build on a consistent platform or base.
This reduces rework for each deployment:
Saving time and money
Makes it easier to develop a consistent experience
Avoids unintentional differences in experience caused by different understands of requirements or coding errors.
I wasn’t to make this a sales pitch! So I can’t talk about the solution…
We believe that it is about getting the architecture right for service provider apps. This enables maximum reuse and can keep get a consistent user experience.

18. A Solution A wallet standard?
GSMA are currently looking into this – they were presenting ideas about it in the “Connected City” at MWC.
Is this feasible? Would the wallet providers be willing to confirm to a standard.
Most likely that a service provider will need to create their own “standard” that they can integrate into each wallet. This will give them the benefits described without the wallet providers having to conform.
When discussing my views on this issue, I was asked if I was calling for their to be a standard.
Other are looking at it.
Don’t believe it is feasible.

19. Solving the multi-wallet problem (commercial)

20. A Solution
As with most deploy issues around secure services – solving the technical issues is only have the story.
To drive mass market adoption, users have to be able to access the service who every is there network operator. This means that a service provider will commercial relationships with each wallet provider.
For large services providers – this is feasible (if time consuming)
But to drive mass market acceptance, small(er) service providers also need a route to market – potentially a place for service aggregators.

21. Thank you.

22. Final thought: There’s a lot more SPs than MNOs….
Let’s make an assumption that the service provider isn’t the wallet provider. The wallet provider will almost certainly be the secure element owner (given the current market that’s a network operator).
So now the service provider has multiple wallets to integrate into. It’s almost certain each one will be different.
I said it the sliding scale was a simplification. Even if the service provider is likely enough to have to deal with wallets at the same point on the sliding scale, they’ll be able to create a similar user experience for each wallet but still have multiple integrations to go through.

23. So what happens if we add multiple SP?
Let’s make an assumption that the service provider isn’t the wallet provider. The wallet provider will almost certainly be the secure element owner (given the current market that’s a network operator).
So now the service provider has multiple wallets to integrate into. It’s almost certain each one will be different.
I said it the sliding scale was a simplification. Even if the service provider is likely enough to have to deal with wallets at the same point on the sliding scale, they’ll be able to create a similar user experience for each wallet but still have multiple integrations to go through.