Grunnlaget for vellykket Fintech-infrastruktur (og flere avveininger å vurdere)

I løpet av de siste årene har feltet fintech-infrastruktur eksplodert med venturekapitalinvesteringer og gründeroppmerksomhet. Mellom fremveksten av Stripe, Plaid og andre kategoridefinerende decacorns; de fortsatte lanseringene av tilbud om finansielle tjenester fra ikke-banker som Apple og Walmart; og den generelle API-ifiseringen av den gjennomsnittlige teknologistabelen, er det mange strukturelle medvinder som driver fintech-infrastruktur fremover. 

Vi ser dette førstehånds på fintech-teamet på a16z. Hver uke har vi det privilegium å møte dusinvis av utrolig skarpe grunnleggere som takler alt fra innenlandske tilknytninger til eksisterende tilbud (f.eks. lønnstilkobling eller aggregering av helseforsikring), til internasjonale versjoner av amerikanske suksesshistorier (f.eks. bankkontoaggregering eller globalt kjenn kundeverktøyene dine (KYC), helt nye problemsett (f.eks. broer mellom web2 og web3). 

Som vi har sagt gang på gang, tror vi i a16z hvert selskap vil bli et fintech-selskap. Med dette i tankene, legger vi ut fire nøkkelkomponenter som alle infrastrukturgründere som opererer i dette området – enten de fortsatt er i idélabyrinten eller allerede er på markedet – må vurdere når de bygger selskapene sine. Vi presenterer også tre deler av veien der grunnleggerteamene må bestemme hvilken vei de skal ta virksomheten sin.   

Must-Haves

Det er mange tilnærminger til å bygge infrastruktur, men vi tror disse fire strategiene er avgjørende for å sikre at din bedrift har et solid fundament og en vei til skalering.

Oppdragskritiskitet: Ville kundene dine bli vesentlig forstyrret (eller til og med tvunget til å stoppe driften) hvis tjenesten din gikk ned? Eller er du bare en hyggelig å ha? Svarene på disse spørsmålene bestemmer direkte prisstyrken, forsvarligheten og den generelle klebrigheten til produktet ditt. Jo dypere du er innebygd – og ofte, jo strengere SLA-er for oppetid! – jo vanskeligere er det å erstatte deg. Selv om absolutt ikke alle vellykkede infrastrukturbedrifter vil bli 100 % virksomhetskritiske, tror vi det er lettere å drive høyere kunde-LTV når kjernetjenesten du tilbyr er helt avgjørende for den daglige driften. Vanligvis, innenfor fintech, betyr dette at produktet ditt er en viktig muliggjører for enten onboarding og kontoåpning/finansiering (f.eks. Alloy, Middesk, Plaid, Sardine, Synapse); underwriting, utstedelse og opprinnelse av lån (f.eks. Adyen, Credit Kudos, Experian, FIS, Fiserv, Lithic, Marqeta, Spade, TransUnion, Vesta); eller betalingsmottak og inkassoservice (f.eks. Moov, Navient, Nelnet, Shopify, SpotOn, Square, Stripe, Valon).

Hvis du er en fintech-infrastrukturgründer som bygger utenfor disse kjernefunksjonene, oppfordrer vi deg til å være ærlig med deg selv om hvor du faller på spekteret av misjonskritiskitet, og identifisere muligheter for å gjøre produktet ditt uerstattelig. En slik mulighet kan være å revurdere kundesettet ditt, siden bedriften din noen ganger kan være forretningskritisk for ett sett med kunder, men ikke for andre. For eksempel: mens oppstart av transaksjonsberikelse som Spade i utgangspunktet antok at deres mest åpenbare bruksområde ville være med personlig økonomistyring og budsjetteringsverktøy, innså de raskt at muligheten som ble tilbudt – en renere og mer tilfredsstillende brukeropplevelse – stort sett var hyggelig å -har og ikke direkte knyttet til topp- eller bunnlinjen. Men da de begynte å selge til en helt ny kategori av kunder, inkludert BaaS-leverandører og kontantstrømbaserte garantiverktøy, innså de at det de tilbød ble helt avgjørende, ettersom det låste opp verdifull nettny informasjon om en forbrukers forbruksvaner— og dermed deres sannsynlighet for å betale tilbake gjeld eller begå svindel. Spade fortsetter å selge aktivt til begge kundesegmentene, men forskjellen i verditilbud mellom de to er viktig å merke seg.

Et snevert definert førstegangsbruk: For å komme fra 0 til 1, er det vår oppfatning at å løse ett diskret smertepunkt betydelig bedre (eller billigere!) enn noen andre er bedre enn å bygge proprietær IP som har mange potensielle brukstilfeller, spesielt hvis ingen av dem er klare på dag én. Plaid gjorde en fenomenal jobb med dette; den hadde som mål å legge til rette for grunnleggende kontoaggregering med bredere dekning og tilby en bedre utvikleropplevelse enn hva de etablerte løsningene hadde i markedet. Mens Plaid umiddelbart kunne ha gått full gass etter alle brukstilfellene muliggjort av bedre åpne bankforbindelser (f.eks. utlån, investeringsaggregering, pengebevegelser, etc.), bygget den veldig bevisst sin kjernevirksomhet rundt kontoåpning og onboarding (endepunkter /auth, /identitet og /balanse) for neobanker og betalingslommebøker. Ved å betjene tusenvis av kunder med denne kjerneløsningen bygde Plaid raskt og effektivt et massivt proprietært dataelement som det kunne deretter begynne å eksperimentere med nye løsninger for å tiltrekke seg nye kundepersoner og øke eksisterende kunde-LTV. Ved å løse ett distinkt smertepunkt bedre enn konkurrentene kunne, etablerte Plaid tillit hos kundene sine, noe som naturligvis åpnet for utvidelsesmuligheter for å utvide overflaten. Hadde det opprinnelige produktet blitt bygget for å imøtekomme for mange brukstilfeller for tidlig, kan Plaid ha blitt utfordret av mer sølete verdiforslag, mangel på fokus, usammenhengende salgssykluser og en mer utfordret utførelse (avsløring: Marc er en stolt alun fra Plaid!) .

Plaid Link Flow:

Gammel konkurrentflyt:

Nøytralitet på tvers av kunder: Hvis du gjør jobben din godt, vil du sannsynligvis ha mange vanskelige beslutninger å ta med hensyn til å utdype forholdet ditt til ankerleietakere. Sebastian Kanovich, administrerende direktør i det globale betalingsselskapet dLocal, diskuterer dette dilemmaet meget veltalende på episode 24. februar av Founders Field Guide-podcasten med Patrick O’Shaughnessy. I de tidlige dagene av dLocal ønsket mange selgere å annonsere produktet sitt til dLocals brukerbase i bytte mot direkte betaling eller en større kontrakt. Selv om det absolutt var et fristende tilbud (spesielt for en oppstart som hadde klart å sikre seg massive kunder som Uber og Nike tidlig på sin reise), ville tilbudet sannsynligvis ha utelukket dLocal fra å fortsette å betjene andre viktige bedrifter (Lyft eller Adidas, f.eks. eksempel) som konkurrerte med disse tidlige kundene. Denne nøytraliteten blir spesielt viktig når bedriften din kjemper om den nye avlingen av standard globale selskaper vi på a16z er så begeistret for. Med mange nye selskaper som ønsker å konkurrere internasjonalt fra dag én, blir areal for interessekonflikter bare bredere. Med dette i bakhodet synes vi det er viktig å holde seg nøytral; som plattform- og infrastrukturleverandør må du behandle alle kundene dine så likt som mulig. Øyeblikket du bryter bedriftens merkevareprinsipper, prisbånd eller produktdesignpolicyer for å bøye deg bakover for en stor logo, er øyeblikket du begynner å sette resten av kundeforholdet i fare. Til tross for NDAer og konfidensialitetsbestemmelser, kunder alltid snakk med hverandre – spesielt når det kommer til pris!

Forbruksbasert prissetting: Vi skrev nylig et helt stykke til forsvar for betal-som-du-gå-priser. For å oppsummere: lisensbaserte virksomheter har en tendens til å gi jevnere vekst og mer forutsigbare inntekter (enhver SaaS-investors drøm), mens bruksbaserte virksomheter er mer utsatt for markedstopper og bunnfall, og derfor ofte antas å være mer risikable. Imidlertid, mens sistnevnte kanskje ikke er like pålitelig for ekte årlig gjentakende inntekter, kan det resultere i mer inntekter og bedre kundebevarelse over tid (spesielt når det kombineres med gjennomtenkte minimumsforpliktelser i hovedtjenesteavtaler (MSA)). En annen fordel med bruksbasert prissetting er at den justerer kostnad og verdi, noe som resulterer i null friksjon for økt sanntidsadopsjon av produktet ditt. Mens anskaffelse av flere SaaS-lisenser eller en ny alt-du-kan-spise-avtale krever at en kunde går gjennom ytterligere forhandlinger og/eller kontraktsendringer, kan forbruk av flere APIer (som gjenspeiler sluttbrukervekst og etterspørsel) skje uten involvering fra et salgsteam eller en kontoansvarlig. Vanlige eksempler på pay-as-you-go-modeller inkluderer SpotOn, Stripe og Square som belaster et prosentvis gebyr av betalingsvolumet de behandler, eller E*Trade og Interactive Brokers som belaster en fast avgift for hver opsjonskontrakt som handles på deres respektive plattformer .

Forks in the Road

Etter at du har forsikret deg om at bedriften din lager mat med de riktige hovedingrediensene, må du vurdere hvilke smaker som vil avrunde retten. Alle alternativene som presenteres nedenfor kan resultere i et Michelin-stjernemåltid – det kommer bare ned til stil og preferanser.

Bør du målrette mot utvikler-først eller business-first-kjøpere? Vår erfaring er at utvikler-første-bevegelsen – bunn-opp-kundeanskaffelse, selvbetjent onboarding, fellesskapsengasjement – ​​har en tendens til å kreve et produkt som gir rene, brukbare data i motsetning til forhåndskonfigurerte moduler eller applikasjoner som pakker inn dataene. Utviklere ønsker vanligvis å bygge sin egen analyse og brukeropplevelse som sin "hemmelige saus", mens forretningsorienterte kjøpere ofte vil ha noe mer ferdig for å møte deres umiddelbare behov på en mer plug-and-play-måte. Sistnevnte kjøperpersona ber også vanligvis om myriader av tilpasninger bakt inn i produktet, mens utviklere gjerne begynner å fikle med produktet som det er og bygge sine egne tilpasninger på langs. Hver tilnærming har sine fordeler og ulemper.

Tenk her på forskjellen i tilnærming til Persona vs. Socure, to selskaper som opererer i KYC-området. For den ambisiøse utvikleren som ønsker å bygge en fullstendig tilpassbar identitetsverifiseringsopplevelse som en del av bedriftens onboarding-flyt, markedsfører Persona «byggekloss»- og «miks og match»-funksjoner over hele hjemmesiden sin (se bildet nedenfor), mens den fremhever «Prøv det nå». " som hovedoppfordringen til handling og gir et "utviklersenter" med lenker til API-dokumentasjon og et statusoversikt. Socure, på den annen side, kjører en mer forretningsorientert go-to-market-tilnærming, der produktet ofte blir referert til som en "plattform" og hovedoppfordringen til handling alltid er å "Be om en demo og priser," aka, snakk med salg.     

 Det er viktig å merke seg at utvikler-først vs. virksomhet-først refererer til personligheten (ingen ordspill) til den typiske kjøperen i en organisasjon, og ikke størrelsen eller typen til selve organisasjonen. Hvis du fortsetter å lese Persona og Socure-nettsidene, vil du legge merke til at begge selskapene har solgt til kunder i alle former og størrelser; Persona har tydelig bygget merkevaren sin rundt utviklere, men har likevel mange store bedriftskunder som Square, Toast og Carvana på hjemmesiden. Det er lett å anta at startups, som speiler utviklerfellesskapet, foretrekker å kjøpe byggeklosser for kjerneinfrastruktur de selv kan forme til et produkt, og at bedrifter foretrekker å kjøpe mer ferdigbakte hylleprodukter, men realiteten er at kjøp avhenger i stor grad av hvilket team i en organisasjon som presser hardest for produktet. Vi vil hevde at store virksomheter kan bygges for begge målgruppene, og faktisk, over tid, vil du sannsynligvis måtte imøtekomme begge. Det er bare et spørsmål om å bestemme hvor du skal begynne og hvordan du først skal posisjonere merkevaren din.

Bør du optimalisere for hastighet eller skala? Er den primære nytten av produktet ditt å tilby kundene en rask, stående start, eller er det et grunnlag de kan bygge på i årene som kommer? Vil de dyrebare første kundene dine og tidlige designpartnere velge å bygge denne egenskapen internt når de har økt antall ansatte og sikret mer båndbredde, eller vil de foretrekke å abstrahere den til deg for alltid? Vi tenker på dette som "eksamenrisiko", og har oftere enn ikke en tendens til å favorisere bedrifter som forankre seg som en permanent løsning i stedet for et V1- eller stop-gap-tiltak. 

Når det er sagt, er det selvsagt mange startups som kan legge til rette for både hastighet og skala. Det kommer til syvende og sist bare ned til pris og kompleksitet. Vurder for eksempel Stripe vs Finix. Stripe er universelt kjent for å være enkel å implementere og utviklervennlig. Som en regulert betalingstilrettelegger, eller "payfac," Stripe gjør det mulig for plattformer å bygge inn og tjene penger på betalinger i løpet av få dager, en løsning som fungerer for alle fra YC-startups helt opp til massive bedrifter som Salesforce og Ford. Finix, derimot, er stolt av å la sine kunder bli deres egen betalingstilretteleggere, et grep som lar bedrifter beholde en større del av betalingskaken i bytte mot økt operasjonell kompleksitet, lengre byggetid (måneder i stedet for dager/uker) og høyere regulatorisk byrde. Finix annonserte nylig at det også har blitt en regulert payfac (som Stripe), og derfor vil tilby kundene begge alternativene: hastighet og skala. Vi tror at gode virksomheter kan bygges som selger enten, spesielt siden (som bevist av Stripe), ikke alltid det ene går på bekostning av det andre.

Bør du tilby et forbrukerrettet merke eller en white-label-opplevelse? I et venture-økosystem der løftet eller oppnåelsen av "nettverkseffekter" ofte er den gyldne billetten til finansiering, kan det være fristende å sakte men sikkert disintermediate deler av kundenes virksomhet i et forsøk på å bygge et flersidig nettverk. Å gjøre det krever ofte at infrastrukturselskaper går over fra hvitmerkede til merkede opplevelser, siden forbrukerne sannsynligvis ikke visste at de samhandlet med produktet eller tjenesten din i utgangspunktet. Med unntak av svært unike omstendigheter, advarer vi mot dette – å konkurrere med kundene dine og innføre merkevaren din i brukeropplevelsen deres er ofte en ledende årsak til churn (eller i det minste, for å skanne markedet for et mer smidig alternativ). Hvis imidlertid å gjøre merkevaren din mer fremtredende kjent kan tiltrekke flere sluttbrukere til bedriftskunder, kan denne tilnærmingen faktisk være fornuftig. Se ikke lenger enn Plaid (igjen) for et annet eksempel. Mens Plaid opprinnelig startet som mer en white-label-opplevelse, skapte det over tid et veldig bevisst forbrukerrettet merke som var bygget rundt personvern, tillit og sikkerhet. Dette var for at forbrukere skulle føle seg mer komfortable med å koble bankkontoene sine til tredjepartsapper og -tjenester når de så Plaid-logoen. Kort sagt, begge tilnærmingene kan fungere her, men det er ofte en delikat balansegang når man går over fra den ene tilnærmingen til den andre.

Det er mange måter å bygge et fintech-infrastrukturselskap på, og vi er heldige som jobber med spillere av alle permutasjoner og kombinasjoner. Så lenge du jobber mot et klart definert, forretningskritisk bruksområde mens du justerer verdi med kostnad på en upartisk måte, vil du ha god plass til å gjenta detaljene.

***

Synspunktene som uttrykkes her er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

 Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Vennligst se https://a16z.com/disclosures for ytterligere viktig informasjon.