Embedded Fintech

I was listening to a podcast by Mike Maples Jr and they had a guy on talking about category creation. This runs along the theme of creation demand vs. capturing demand. The downpayment.gift positioning is definitely about create new demand for mortgage lenders instead of simply capturing it. We are adding value and trying to help buyers become buyers. It’s a completely different idea to the typical lending pitch.

So anyway… fresh off this category creation deep dive… I was listening or reading someone about Embedded Fintech (or Embedded Finance). This is where financial and SaaS providers sell to other businesses or even other SaaS providers and offer financial related apps, API’s and other integrations to allow them to offer a financial product to their customer. I refer to our Lender customers as Partners. This is a side-effect or having a bit of a two-sided business. Clients or home buyers and Partners or lenders. I hate calling it a marketplace. We are not building a marketplace in the traditional sense. It was more like a co-branded, vertical SaaS. (not white labeled, cause the downpayment.gift brand will always be there)

So under this category of Embedded Fintech, we allow Lenders and Brokers to embed the “down payment savings and gift account” product into their offerings (online or hybrid on and offline). We have a roadmap of tools for lenders to further embedding the entry point to the sign up funnel… widgets for homepage, links, buttons, and so on. Curretly, it takes them away to downpayment.gift for the registry gift account. I could foresee a future API centric or custom domain integrations were to looks seamless for lenders/brokers. This more white labeled, while retaining the Powered By co-branding for trust, would be squarely in this Embedded Fintech category.

Some of the “news” and PR writing about this category list some of the most basic of applications as in this category… for example, Blend or any webapp that is white labeled and take the 1003 app and documents could be considered Embedded Fintech. Not 100% sure I would bucket online LOS sytems for taking a loan app as being novel in this category… but okay.

Apparently the Embedded Fintech category has been brewing in the VC or Fintech communitities. Embedded Finance is a parallel category. Apparently offering things like branded debit cards might fall into that category.

The idea of both names… that all platforms or brands could be a Fintech too. …offering financial products to their customers without becoming a depository bank.

I spend a little time research this catergory of embedded finance, embedded fintech. I don’t think that customers are actively looking for this category… but it’s an investor positining.

Instead of being Fintech-lite or Fintech-ish… we can take this “Vertical SaaS” and “Embedded Fintech” positioning. The two-sided marketplace mental model is out the window!!!

Co-branded Fintech aka B2B2C. I had been tossing around this B2B2C acronym, but it’s confusing and marketplacey.

Okay… so we are Vertical SaaS / embedded Fintech. I’ll keep exploring this. I did add this in the Business Model side in the investor pitch deck.

Stripe Connect Custom account types

Our Stripe Connect integration at the MVP stage was using the Express Onboarding. This is where all the sensitive data is handled by Stripe’s UI. The verification of identity and accounts. Makes it dead simple.

Unfortunately, it saved these account in the Dashboard as Business and not Individual. No matter what I did, I could not get the Express API’s or Oauth interface to save as Individual.

I finanlly reported my problem to Stripe Support. Ultimately I think this is the behavior they are supporting and I pointing out issues with their documentation. I can’t believe this is the first time someone has encountered this. The fact that the API was doing something inconsistent with the docs was a bit mindblowing.

I suppose it may be worth taking the sample app on Github and try to duplicate my problem with Express account and business_type = individual. Maybe it was specific to my environment.

I did not want to get a ton of customers onboarded and have them tagged as a Business in the Dashboard. It also could present a “conversion” issue since people could hit the Business Type verbiage and other stuff and stuff in confusion. This seemed like a showstopper on the initial architecture.

Swallowing the frog and jumping to Custom

Regardless, the benefit of this issue is pushing off the sales and content efforts and going deep into code for a week and a half to code up and adapt our app for the Custom Type.

We are still using Stripe’s UI for Verification of Identity. This could help with conversions. ..but we are pushing out the requirement to enter a bank account or link a debit card.

Basically, we remove that Link Account step and the #3 steps becomes Verify Identity. The client, home buyer, can decide to start a campaign/registry and only link their private bank or debit card when they have actual money to withdrawl. It’s a brilliant step forward and should improve conversions. We still require tax id, name, address and date of birth… but not the bank account.

This give them time to possibly setup a new, separate account for down payment savings. This is what we want them to do anyway. Some Partners could be at depository banks and want to create an accout there.

This also make it easier to add a step to create a new account for long term deposits using API’s or Open Banking type fintech APIs. This was a long term direction… it’ll make more sense in the flow now.

We have a configurable delay before contributions are swept into their account. We seem to be a 21 days, but might extend to 28 days. This delay also gives time to investigate fraud causes before sweeping funds to external accounts.

The app polls Stripe for account status. At the start, with a successful verification of identity, we are at charges_enabled. …but payouts are disabled until we link valid external account(s). So we now ask for Debit Cards (via secure Stripe JS) and the Bank Routing for ACH. We don’t store any of this data. It goes straight to Stripe for tokenization. Is that a word?

Onboarding flow is better for conversions now!

Verify identity first, link bank account later, after first contribution. Lost of changes, testing. 17 files committed.

Checked in the first interation where we poll state from Stripe, charges_enabled? payouts_enabled?

Fixed last remaining Stripe API call to remove use of connected accounts’ api key use and only use the account id with our keys, per Stripe security recommendations. Now that we are off Oauth, this is possible.

Refactor onboardinglinks and callbacks.

Beef up error handling, specifically for logging code for Stripe Errors and Exceptions

Other misc

Recorded some videos of signup and onboarding.

Unlimited Pledges; limits for Contributions (charges)

Coded configurable charges limitation. App enforce limits, $8000 to start. Validation and configuration of charge limits. Single charge is still that max contribution. Pledges can go up and over the goals, price on the registry.

We are Unlimited on Registry Amounts, unlimited pledges… however, limited contributions that are FREE in charges and debit card usage. Example $8,000 x 2.9%. Limit our liability while allowing clients to be successful in raising money for the home down payment.