Big Tech in Financial Services (Part 2) - Google's FS Playbook
10 min read

Big Tech in Financial Services (Part 2) - Google's FS Playbook

In the previous piece we saw how Amazon is building a bank for itself, to be primarily used across its own ecosystem and to make the life of its platform participants a lot easier - for the ultimate goal of buying more and selling more on Amazon!  

This piece is about what Google (as a complete contrast to Amazon's reason of getting into financial services) expects from its financial services initiatives i.e. gather more data about its advertisers' customers so that it can help them target their TG better.

Google's Financial Services Playbook

Today Google has a lot of data about the user and a lot of proxies for the data it lacks.  For e.g. A permanent location, Type of Phone etc. as a proxy to Income / social strata etc.  This may lead to false positives like kids using expensive phones on behalf of their parents or a house help using an old phone from the employer and staying at the place of employment etc.  Thus the targeting using these variables can result in a lot of wasted ad spend on behalf of the advertiser.

Google's answer to this problem is - Well, to get into Financial Services, scoop up as much financial data about the user (with user consent) and might as well make some revenue on the side!

Financial Services Infrastructure

Oil companies built a legacy business by laying down the infra to transport the oil from point A to point B.  The larger the reach of the infra, the more the customers (and suppliers) and more the profits.  Since data is the new oil, Google has laid down the pipes for transporting the data at nearly zero cost and already has a lot of "free" infrastructure lying throughout the globe i.e. Android devices paid for by the users.  These devices are the pipes using which most of the financial services providers (incumbents) are interacting with their customers.  Google just has to plug itself on top of these incumbents and start controlling the UX (and owning the customer relationship) eventually.

This is a classic platform business where the business has been started for a purpose that is different from the real revenue stream of the company.  If you paid attention, across Amazon's ecosystem as well, the purchaser (consumer) is a customer of Amazon and not of the seller thus the consumer can be provided an alternate seller in case Amazon decides to remove the earlier seller and replace them with someone else or itself.  

The purpose of the platform is to provide the consumer with the product or service, irrespective of the underlying seller/service provider.  Thus in Google's case the underlying FS provider can be anyone.  As long as Google controls the infrastructure (the device) it can control who the service provider of the desired service is as well.  

Since the underlying product is a commodity, it can be replaced with a similar or better supplier with the customer having negligible impact.  E.g. the entire checking account of the customer can be emptied (using google pay) and the money can be wired into a new account with another bank (opened via Google plex) and data of the customer can remain intact in an archive.  The associated loans, credit cards etc. can also be moved to some other "service provider" with the customer having nil to negligible impact.

Ecosystem Play

Google already has a well oiled flywheel working for it in terms of PPC (product per customer).  The customer on Android is most likely using Gmail, Maps, Google Pay, this gives Google unprecedented leverage in terms of getting the customer to perform certain actions with ease which they are anyways going to make later on.

  • Payments

Payments was the earliest foray of Google in financial services (it normally is the earliest foray for most of the tech companies considering the ease with which this can be setup and the captive audience that they already have to use this payment mode across their own ecosystem).  Today Gpay is a force to recon with in quite a lot of geographies.  In India, it's the 2nd largest PSP (payment service provider) for P2P Transactions.   In US, Gpay is the only Bank account play of Big Tech in the challenger bank category (without a banking charter) in partnership with Citi Bank and some other banks.

GPay today hosts a lot of services from comparison of financial products, to serving as a marketplace of financial products being offered by other service providers (platform business) where Google controls the UX and the customer relationship and the service provider just fulfils the role of "delivering the service".  One more reason to start with payments is that the payments platform can generate enormous amounts of data and this data can then be plugged in various use cases to optimize the network effects of the platform, refer below use cases:

Consider this example: Your credit card company sends you the bill (statement) via email, SMS etc.  This email is more often than not on Gmail, GPay simply has to scan through the emails to give you a prompt that your card bill is due - click here to pay (via Gpay) and that's it.  With 1 single click all apps, services (banks or otherwise) that assist in keeping reminders for bill payment and to assist in bill payment or processing card repayments have been done away with.

Using this same example, Gpay can better predict your cash flows and can give a more accurate representation of the finances in the personal finance manager module of Gpay (which can keep track of expenses on an auto pilot - via email + cc statement & receipts paid via Gpay reconciliation).  All of this without the customer having to enter any data manually in any 3rd party app.  With another click all personal finance managers, expense trackers are down the drain.

Stretching this for one more use case, imagine you step out of your house and want to drive to a restaurant (using Maps) and Gpay before you know it gives out a pop stating to use Gpay to pay for the food and get rewarded blah blah.  Or even better you seem to be in close proximity of your friend who also seems to have spent equivalent amount of time at the same location - might as well split the bill ??  With another click all split payments app and book keeping apps are out of the phone.

Data Play

Though these use cases sound far fetched, Google actually has tested most of the features that the think tank team thinks is "doable".  The entire gameplay here is of the data of the user and the richer the data gets, the more Google advertisers will be able target (retarget) the users for their products.

Apart from advertising, there is huge opportunity in using the data for underwriting lending products for the users without having to rely on credit unions or even use the data to better price the risk associated with insurance products to be offered to the users.

The below use cases highlight that these are more features rather than the core product itself, all of these are in some shape and form being used (or under development) to be plugged in the core product (like a checking account) and scaled from there on.  This also shows that in case Google does not decide to go ahead with these moon shots, this tech can definitely become the defacto tech being used by financial institutions i.e. Google can become a technology vendor (in more ways than existing) to large financial institutions (beyond cloud infra etc.).

  • Lending relationships with customers (users)

Apart from the basic underwriting parameters used by legacy financial institutions, Google has richer data about the customer like the frequency, value of transactions done via Google Pay using which the total spends can be derived & used as a proxy for the customer's income and they can then be offered an unassisted loan to be availed instantly.

If not a large ticket size product, small ticket (BNPLs) loans can be offered right at checkout or billing at retail stores to pay in equal instalments.

In all of this the entire risk of the loan lies with the lender and the customer relationship (including customer service like repayments, statements, foreclosures etc.) are managed by Google using Open APIs of the financial institution.  And since Google acts as an originator of the loan (sourcer) they're entitled to a sourcing fee + a recurring split of the transaction every time the customer draws more loans.

In any case if the lender decides to cut ties with Google, Google can simply sell off the portfolio of the loans as a debt instrument (debt obligations) to another lender, square off relationships with first lender (for all customers at once) and the repayment of the customer continues in favor of the new lender i.e. True Portability of Financial Products.

If not loans, Google can get into a Credit Card (powered by a bank) and manage to do all of this with a Credit card and not a loan.  The revenue streams change to a sourcing fee + recurring share of interchange from the card spends.  

  • Insurance

Google pay already knows your financial worthiness (as above) & Maps will know how you drive, where you work, where you live and so on.  Using this data, Insurance premia can be more accurately priced for the risk associated with users and not only on the age vs medical history logic that legacy insurance companies rely on.

This can cause quite a stir in the overall risk based pricing for insurance and reinsurance companies.  

Again the entire risk is carried by insurance companies where as Google can enjoy the sourcing fee + recurring fee on every policy renewal.

Not only life and health, Google can help in pricing other policies like a Car Insurance (basis your driving quality using Maps data) as well.

  • Investments / Savings

Using the expenses and income tracker of Gpay, Google is suited uniquely to offer investment options basis spend habits of the user, without the user having to spend much time in searching for the right avenues to invest the surplus cash.

Interestingly, this can just be modified to round up your expenses to the nearest 100 and invest the spare change in a money market fund (Alibaba via Alipay is already doing this and has the largest Money Market fund in the history of Money Market Funds) on auto pilot.

  • Lending relationships with retailers (money receivers)

Since this is a 2-sided platform, Google has data from both sides of the network i.e. customer (payer) and retailer / seller (payee).  Using the data of receipts of the payee, the small business owner who accepts Gpay as a payment mode can also be given a small business loan basis the transaction data being the proxy for revenue and thus profitability.

  • Payments acceptance solutions

Google already has the largest number of smart devices in the hands of users (customers) and retailers (seller).  With an integration (or acquisition) these devices can be converted into payment devices (tokenized cards linked to Gpay or NFC) and with a simple touch or wave, payment can be credited to the seller - all without the need of a credit card acceptance machine etc.

Checking Accounts / Challenger Bank

Google is by far the only big tech that has actually ventured into the Bank account category, although in partnership with a bank, which also shows that big tech typically wants to stay away from any regulation bound product and want the compliance burden to be on the FI rather than on itself.

Google Plex Account

This product in its true sense is the real core of financial services aspiration of Google.  This is an account being offered by a licensed bank and is fully opened, operated and managed from within the GPay app itself.

This runs on Open Banking architecture powered by the underlying bank (can be any) and gives all the above use cases a solid footing to start scaling (e.g. split payments, BNPL, investments, expense management that are already a part of planned roll outs of flex accounts).  Other products like insurance is being sourced as a standalone offering powered by an Insurance company (at the moment).

Cross Border Remittance

This post is for subscribers only