(techno music)
- Coming up, if you're in a highly-regulated industry
and want to innovate with the cloud,
we're gonna meet with one of the world's leading
international banks, HSBC, to learn how.
And we're going to explore how they built an intelligent,
secure and analytics rich, digital payment platform for
their PayMe for Business App in Hong Kong on Azure.
And to do that, I'm joined today by Alessio Basso,
Chief Architect of PayMe from HSBC, welcome.
- Thanks for having me on the show.
- [Jeremy] Thank you, so congrats on the recent launch
of HSBC's PayMe for Business App,
and also we're looking forward to really hearing a lot from
you today in terms of how you've built it.
Now I know that HSBC is really one of the largest
banks in the world, and it's strategically done
a lot of work in terms of educating regulators in the
financial services sector, really about the benefits
of cloud and how it can be used to store data securely.
Not only has HSBC been a thought leader but it's also
really led by example in terms of how to harness and be
the first mover in terms of going to the cloud.
- Yes, we've taken a pretty progressive mindset
in terms of our technology strategies.
We know the regulations are important in order to
make sure that everybody in the industry
adheres to the same checks and balances.
But this regulation should not hold us back,
should not prevent us from
continuing innovating for our customers.
We know that we need to have,
and we do have, good strategies in terms of
information security and risk management,
and we can deliver on those strategies
with the tools that the cloud gives us today.
- Right, so with HSBC, given it's global footprint,
must have a lot of legacy on-premises data centers
and operations, right?
- We do, we have over thirty-nine million customers
and around sixty-six countries and territories.
So we have a pretty massive footprint.
We operate our own data centers in 21 of those countries.
Our goal though, is to be fully on cloud
within the next five to ten years,
adopting a mobile-first business approach.
This of course is important in places like Hong Kong where
the majority of the population owns more than two devices,
so everybody does everything on their mobile phone.
And of course this gives us the opportunity to rethink
the banking experience and the services that we deliver
to our customers.
- Right and in Hong Kong, especially
and even in the rest of Asia,
you see that a lot of people are
really opting to just carry their phones with them,
without having to bring cash or maybe their wallets
it's really gotten more convenient in terms of
making payments just from their mobile devices.
- That's right, this was the motivation for the
PayMe for Business app that
I'm gonna walk you through today.
But we actually started first by
supporting cashless in a P2P fashion.
HSBC PayMe app for consumers was launched in early 2017.
You can think of it as a social payment application
that allows you to send money to your friends and family
without asking for their phone number or for their
bank account, all for free.
And the app is used widely among people in Hong Kong
to share money in social situations.
Like when you go out with friends and share a meal,
or you do an activity together and
we have now more than 1.5 million people
using it in Hong Kong.
- There's about six million population in Hong Kong
so that's about one in five people
are already using HSBC's PayMe app,
and it really gives you a great customer base
to get started with in terms of
applying this to merchants so that they can make payments
as they shop and buy other consumables.
- It does, absolutely.
PayMe for Business applications
allows businesses to collect payment in real time,
and that's unlike traditional payment methods
like credit card.
- [Jeremy] Right, and that's going to take a few days.
- [Alessio] Absolutely, with PayMe for Business
you have access to the money you collect in real time
anytime you want.
And we, of course taking advantage of all the
great bank-grade securities that HSBC provide.
On top of that, it's fast for the consumer.
98% of all of our transactions terminates
within 500 milliseconds and we have built-in intelligence
so that the business can use data to analyze the sales trend
and you know have ideas of how to grow
their business even further.
On top of that, big companies can also use us.
We have API that you can integrate.
For instance if you have eCommerce website
or if you have a POS device,
so we cover the whole spectrum of merchants in Hong Kong.
- So it sounds like a great app
and a lot of people are using it,
why don't we dig into the architecture of how you built it?
- Of course, so the app is a cloud native application.
And our first decision was to develop
using a microservice-based architecture.
So the app consists of a dozen or so microservices,
each one performing a different function.
For instance we have our user and business profile services.
We have an onboarding microservice that you call
when you register to the service for the first time.
We have payment transactions and reporting,
to perform payment and get information about those.
We have a security authentication microservice,
which tells you the level of authentication you need to do
to perform different functions within the app.
- [Jeremy] Makes sense.
- [Alessio] On top of that we also have a social.
Think about managing the interaction between
people and people, and people and merchants.
We do have a timeline service,
that serves the list of your transactions,
but also insights.
We do have a notification service
that takes care of push notification, email,
SMS or whatever else. - [Jeremy] Right.
- [Alessio] We have a QR code service,
and we do have an OCR service,
which is used when you register for the service.
We ask the customer to take a picture
of his or her Hong Kong id.
So we use to extract the data from the Hong Kong id.
On top of that we also have FAQ and messages,
which are related to the in-app support feature
of the application, where you can contact
the support people, chatting inside the app.
- Okay, so those are all the services,
and they're all waiting to be called in
in the event of a transaction?
- Yes, they are.
Let me guide you through a typical transaction.
- Okay.
- [Alessio] When the merchant wants to collect a payment
he or she types the amount on the app,
and the app calls the QR code payment service.
The QR code service generator visually represent
the transaction that's displayed on the device
of the merchant.
Then the consumer takes his PayMe for Consumer app,
scans the QR code, and the details of the payment
are displayed on the screen for confirmation.
You can confirm by fingerprint or face id,
and then you call the payment transaction microservice
that processes the transaction.
After that, of course, the notification service
sends a notification to the consumer,
as well as the merchant,
and when the merchant gets the confirmation,
then the consumer can walk out of the shop with the goods.
- Cool, so we just walked through all the different services
kind of interact as part of the payment process,
but do each of these microservices then
run independently from one another?
- They certainly do.
Actually, we designed them to be specifically independent.
Each microservice is independent
and is also having its own copy or its own instance
of each of the Azure services that it is using.
For instance, a microservice may have an Azure database
for MySQL service to store data.
It may have its own copy of Key Vault, Redis cache,
Azure Event hub and so on and so forth.
This level of isolation is helping us in two factors.
First is it makes it easier to really enhance security,
you know, when everything is isolated.
- [Jeremy] Right.
- And it also helps increase the uptime of the application.
If the microservice or any of the
independent services have an issue,
only the functions that are provided by that microservice
become unavailable.
So the app and the rest of the other functions
keep working as usual.
- That's probably pretty rare
that something goes down, right?
- That said, it's very rare that something goes down.
- Right, right.
So we just talked about how the microservices then help
in terms of resiliency and
really being independent from one another,
but do they actually help in terms of scaling out
when you have more demand on the service?
- They do, they do.
For instance, we have certain period of the year
where we have more traffic,
like the Chinese New Year festivities,
when people go out more and
they like to send gifts to each other.
In this period we scale out services
like the payment transaction services,
but we don't have to scale out much other services
like the onboarding services.
At the same time, we can scale not only the computer layer,
but also the database layer,
we can create direct replicas of the MySQL databases,
and we can serve the read-only queries
as well as the analytical queries from the reader replicas,
without impacting the main database.
- So no impact then in terms of performace
on the main transacting side,
but have you perf tested this and low tested this,
how many transactions you can actually perform?
- We did, we did.
We went up to 500 million transactions per day in our test,
so we're pretty confident that we can handle these peaks.
- Wow, wow, so I saw also in the earlier architecture view,
you're using Azure Key Vault really for secrets management.
How do the services then securely communicate
with one another?
- Right, so, each microservice runs within its own subnet,
and they all communicate with Azure services
like database or cache or storage.
Using service principles and credentials
that we put in Key Vault.
We also use VNET service endpoints,
which is a feature of Azure services
that manage services that typically are on the cloud
somewhere and then managed, look like a local endpoint
within your own VNET.
So from the point of view of the microservice,
it's a local call to an endpoint
that exists within the same VNET.
- And that's great, because even though
you might have some services on cloud,
and some in local data centers,
they all think they're on the same network.
- They do, they do.
And this capability is critical in our security design.
For instance think about in the cloud, everything is public
and every service has a publicly accessible endpoint
on the internet, and it's critical that
all the communication are authenticated and encrypted.
The traditional view on prem is that
you have a secured perimeter,
and then everything inside this perimeter is secure.
With VNET service endpoint, we get the best of both worlds.
We still adopt the secure model of the cloud
to connect every transaction,
but we can talk to services as if they're all
within the same secure perimeter.
- Right, and this really helps especially when
you think of security teams
if they've got perspectives maybe where they want to
lock down everything within the perimeters
so that resources that are internal are deemed safe,
but maybe not the external sources.
This way it all looks like it's internal.
Now what are you doing in terms of controlling traffic
coming in and out of the subnets?
- So we use a network security group,
and we have a base rule that denies
all inbound or outbound traffic from our VNET.
This way we can add additional rules to explicitly allow
inbound or outbound traffic from or to IP,
that we know we have to communicate with.
And this gives us an extra layer of security and confidence
that we are allowing only the traffic
that is supposed to be there.
The other thing that we do is that we automate
the deployment of these rules, as well as of the services
and everything that is related to the application,
so we completely removed the insider risk
or the human error risk from the picture.
- Right, so these are all security measures effectively
blocking all the traffic that you don't want,
making sure they automate.
What about threat modeling,
are you doing something there as well proactively?
- Yeah, we do, it's part of our risk management process.
So we identify the possible risks,
and then we have to identify and implement
mitigations for these risks.
One thing that makes our life easier is that
there are features in some of the Azure services
to make this process easier for us.
For instance, there are features like
Advanced Threat Protection in the Azure database for MySQL
that already monitor for events
that are associated with some particular risks,
and raise an alert if any of these events happen.
Let me show you that, how we do it.
The other day I got an email,
a notification like the one you see on the screen here,
and it says an unfamiliar principal
successfully logged onto the server.
This means that a user credential that we have
was used to connect to that particular database
from a location that was not a usual one.
So I told you that every microservice is isolated,
so that database expects connections
only from all the instances of that particular microservice.
In case we have a connection coming in from somewhere else,
this is an unusual situation that's
automatically flagged for us for investigation.
- So how do you enable this then to actually start working?
- Yeah so when you go to the panel, the database,
you select the database server,
for instance the business profile database,
and when you go here you see that
Advanced Threat Protection in my case is enabled.
And that's the switch that you have to flip.
So when you flip the switch on,
then this email is notified when something unusual happens.
- Right, right, and also you can also view those alerts
from inside Azure Security Center now.
You're also able to protect things like microservices,
their data, monitor activity within the network,
but why don't we talk about the analytics platform
and switch gears a little bit, what have you done there?
- Yeah, for us the analytic and
the data part in particular is key.
PayMe started as a social P2P application,
where transactions were the main focus and in reality though
we discovered that the application is useful because
of the network that the participants on the platform create.
Like people will communicate with other people
or person paying a merchant.
So we took all the transactional data,
and we put it in a graph and data model using Cosmos,
and that's what we use as our analytic store.
On top of that we use Databricks as our data platform.
That we use to stitch together all this data interaction
and we use that to perform both data engineering workload,
as well as data science workloads.
- And how does this all then serve the customer?
So if you're a merchant or consumer,
how do you benefit from some of this stuff?
- Right, so, one example is that we monitor interaction
on the platform to spot suspicious sequences
and then we either alert the customer
or do corrective actions.
The way we do it is that we streamline a lot of the data
that we have in all our different data stores.
We have transactional data stores, we have Event Hub,
we have storage, into Databricks.
And when in Databricks, we refine this data,
so we ingest raw and then
we move to clean staging model we call it,
until the data that's connected together
is ending up in the graph format into what we call SLIM.
It stands for Simple Lightly Integrated Model.
And that's the base that our data scientists use
to run the models.
- So is this process then to get it into basically
that conversion a batch, or is it a real time process?
- We try to make it as fast as possible.
So some of those data is actually ingested.
Some is processed in place, and just to give you an example,
the click stream data that we get to measure
user interaction in the app is ingested
directly into Event Hub and then it goes into Azure storage.
And then we don't move it from there.
We access it from Databricks
so we can perform SQL queries on that,
but the actual data never leaves storage.
- So you don't need to move the data?
It stays in its normal place?
- Yeah for some of the sources.
Like in ETL, without the transfer.
- Right, right, so it's more efficient
'cause you're getting a remote view effectively
into the data so it's virtualized in a way.
- Correct, correct.
- Very, very cool.
So how about in cases where it's not real time in nature,
what do you do there?
- Yeah, one case for example that is not real time
is the transaction classification.
We want to understand what our user used the platform for,
so that we can provide new services to them.
For instance, let's say that we take a taxi together
and we have to share the fare.
You send me a payment message and you type taxi
from Kowloon to Hong Kong. - [Jeremy] Right.
- So from there we can identify and classify this payment
as a transit or a transport payment,
and we do the same for a number of other categories.
The way we do it, let me show you.
As I mentioned we do both data engineering
and data science workloads on Databricks.
So the workload here is a notebook.
What you can see here there are,
I'll walk you through the steps.
The first step is importing libraries.
Data scientists can import all the
machine learning libraries that you're used to.
And then here we do a bit of data engineering,
which is we load all the data so that it's available
for the notebook to process.
And then we do all the usual steps that you may expect
when you do transaction classification.
So we analyze the text, we removed numbers from the token.
We also looked at emoji, so if you have a bowl of rice,
that classifies as a-- - It helps to classify data.
- It does, it does.
And you know after we identify L1 and L2 topics,
then we save it on Delta, and then it's,
we display it on dashboards,
like the one I can show you here.
- [Jeremy] So then you can visualize
some of the work that you've done there.
- Correct, so you see here on top of the screen,
you have the L1 categories for the use cases,
and then we have stats and numbers,
and this will help us identify what the platform is used for
so we can focus on providing in the future
specifically for that particular use case.
- This is really great stuff,
'cause it's gonna actually allow you to make
apt decisions in terms of improvements
that you might wanna make in the future,
but can you share some tips maybe with the folks watching
how they would build out something similar
for their environments today?
- Sure, the real lesson learned from our experience,
the first one is we used managed services because
with our limited and small team,
we could focus on the application,
and to solving problems for our customers,
and we didn't have to spend effort
managing the infrastructure.
And this is what allowed us to go from
ideation to live in just a few months.
- Right, right, so that's a big deal.
So go on PaaS services when you can so
you don't have to spend as much time managing the servers,
and just managing your code and building your app.
- Right, and the second thing is
when designing your architecture,
this isolation concept that each microservice is isolated,
helps you to reason on security,
but also it helps increase your availability.
- These are really great tips,
thanks for doing this today Alessio.
Also if you want to check out HSBC's PayMe app
you can learn more at the link shown.
If you're in Hong Kong you can sign up for it,
start using it today, if you're not using it already.
That's all the time we have for today's show,
coming to you from the Microsoft Technology Center
in Bellevue, Washington.
Thanks for watching, and we'll see you next time.
(techno music)