Tom Purves – Product Management, Fintech & AI

Signing big customers is hard enough, but it’s only half the battle. There’s an adage in fintech startups – banks can take longer than you can stay solvent. Especially in the current market. I’ve built SaaS products that could take one customer just weeks to go live with, and another customer literally 18 months from signing. Expecting regular project meetings, integration support from you all along the way. 

When a big customer lags on going live, it’s not just lost revenue opportunity. It’s also likely a significant cost in distraction and resources supporting that customer in their integration project. Resources that could have been better spent in getting after the next customer and the one after that.

Here’s a few of the recommendations I’ve provided to my own advisory clients and portfolio companies when they (inevitably) encounter problems with customer integration delays.

---

Support my work and get these posts directly to your inbox:

---

Pricing Strategy Sticks and Carrots

The goal here is both to create a better sense of urgency, and practical deadlines for your customers. But also to help you de-risk when you can start seeing, at least some, recurring revenue from each new deal. A key insight here is that most customers don’t think their project is going to be the one that goes off the rails and gets delayed, so some of these are easier to negotiate into contracts than you might think.

Start your recurring billing clock at time of signing. Make sure you have a component of your billing (a minimum volume, a monthly/annual license fee) that is recurring, not tied to volume, and that starts either immediately at signing, or within a fixed time from date of signing. 

Charge for integration support. Set a modest but reasonable integration fee. You may waive it, particularly for first-mover customers, but set the value of integration support in the minds of your customer. But then also make it a metered or recurring fee.

Cap integration support. Don’t let difficult customers drain your resources indefinitely. Whether you waive it initially or not, set an expectation that your team will provide a fixed amount (in hours, or for 30 days etc.) of support. If the customer needs more than that (intentionally or otherwise) then let them pay for incremental cycles of support. 

It’s not just about the one-time integration. Set expectations in your contracts clients will have to keep up with your future versions, including any reasonable level of retesting or reintegration over time. You can also build in provisions for “extended support” where your service fees escalate in price if clients can’t keep up with some minimum reasonable upgrade cadence. 

Pricing incentives. Helpful  for unproven early stage products or network-value products. Provide pricing incentives for customers going live early, for participating in beta testing but also contingent on going live.

Air Cover

Arm your champions inside the customer’s organization. Think of your job as to make your main champions inside the customer look like geniuses to their peers and get them promoted. 

Do the customer’s job for them. Give them fill-in the blanks business and ROI models. Sample project plans. Sample test plans. I used to always build a mock bank app (see dogfooding) both as a test harness, UX testing tool and demo my own SaaS products, but ALSO as a reference implementation to share with customers

Support all the stakeholders. This one should have started early in the sales cycle. But it means having resources to help your customer team talk to legal, security, regulatory, ops, finance etc. There will be common questions/concerns everyone has, arm your champions with ready-to-go tools, collateral and answers.

Don’t forget the product as soon as it’s launched. Make sure they don’t forget to actually communicate, promote and actually use this fancy product they just worked so hard to buy and integrate from you (I’ve seen it happen). Help them with marketing, communication examples and templates, post-launch best practices to drive usage, metrics and reporting to provide feedback.  Put marketing clauses and potentially associated budget expectations in contract. As well as your ability to publicize the work/case study it.

Sometimes the contract can wait. When it’s not the technical integration but the commercials/legal, don’t let client legal be a blocking factor. You can start integration without final paper. It’s not the best practice but I’ve actually gotten major banks live in prod with an integrated product before all the final contractual and redlines were sorted out. Which means it can be done!

Design, Dogfood and iterate your Integration Experience

Clean API design. This means following and not breaking (without good reason) standard patterns like Restful API and well formed JSON. Be consistent. Try to make your APIs, data types and validation standards feel like they came from the same author and engineering philosophy. Conway’s law will creep up on you, but try not to make understanding your own organizational structure and history not your customer’s problem.  

Developer Friendly Sandboxes. Inline your sandbox with your developer documentation. Allow developers to test and learn api behavior within the online docs themselves. Provide samples across multiple common languages/frameworks. Try to deploy all your products to shared sandboxes to better enable developers to test and experiment with creative solutions, potentially composed of multiple products/apis. 

Dogfood and iterate on your integration patterns. Build a mock customer app and integrate your service to it. Document your experience doing that. I’ve gone so far as to hire a third party shop to attempt to integrate an early version of your product, only using your first draft documentation. You will learn a LOT from that experience. 

Use generative AI. It’s actually pretty easy to train/embed an LLM on your product and integration documentation. Use that to help you more quickly spin up integration collateral, even highly customized for specific customers and usecases. Use that as an internal tool/reference, or just expose that LLM directly to customers as part of your toolset. GenAI can also be quite useful for generating synthetic test data. If done well, synthetic data helps to solve for privacy, security and compliance problems of how to test against realistic production data – without actually using real data.

Keep as much server-side as you can. Generally, the fewer the lines of code, data or logic the client has to own the better. Lower surface area means, less to build, less that can break, is easier to secure, version control and maintain later. For SDKs in particular, what’s the bare minimum of static code that needs to live client side or as native-ap code vs code can be loaded dynamically at runtime? You can update and improve your server side code continuously, with a big enterprise client, you might be lucky to get them to come back and upgrade your integration more than annually. 

Do the customer’s UX research for them. I’ve mocked up a big banks mobile app and UX tested and optimised the user experience with 3rd party research reports to back it up. Double bonus here, saves your customers time, and mitigates risk of big banks over-complicating or just mucking-up the end-user UX (which you just know they are wont to do)

Pave the elephant paths. For better or worse, your first integrations tend to be all hands on deck affairs. Engineering, product tend to be deeply involved. Bugs are found, key assumptions have to be corrected, gaps in documentation needs to be sorted out, new onboarding processes invented as you go. But your goal should be to make each new customer smoother than the last. Hopefully after just a few, you are handing over a repeatable playbook over to dedicated (and more scalable) support teams.  Make your integration machine continuously better, faster and lighter with each new customer. Track KPIs on integration speed and resources consumed to know if you are making progress. 

What’s your take?

Do you love these suggestions, hate them, have even better ideas I’ve failed to mention? Leave a comment and let me know.

I’ve gotten versions of this question recently from bankers and investment-analyst clients.

It’s certainly messy. There are multiple countervailing trends in the macro economy that make this a complex picture. Rapid shift in rate environment has changed the mix in usecases for embedded finance, credit and BNPL models are more challenged, while high deposit yields create new opportunities in treasury products. When I talk to platform providers in embedded finance I hear that yes, deals are still happening but there’s definitely been a mix shift in customers and usecases over the last year.

Prominent bank failures in the US and Europe are not helping anyone either. These are further having a further adverse chilling effect on both bank liquidity and regulatory scrutiny. On the risk appetite side, there is a real danger of ‘baby with the bathwater’ as regulators and bank directors may be prone to look at anything creative as a risk rather than as potential innovation. Regulators are going to be leaning into their ‘protect the banking system’ mandate rather than the more open minded, lets stimulate competition and innovation.

US Banks are facing potential capital calls to replenish the FDIC reserve. Traditional deposit liquidity is chasing yields to money markets further pressuring liquidity. The yield curve and the lending market are upside down.

Embedded finance is also dependent on partnerships/customers with fast growing fintech startups, banking-as-a-service platform integrators and the like. But a significant share of fast growing fintechs over the last few years may have grown too fast, over raised, and could be now short of continuing capital. Expect to see a lot of consolidation and thinning out in the BaaS and neo-fintech space through the rest of the year.

And yet… Where there is turmoil there is opportunity. An 50-80% haircut in valuations create opportunities for acquisition, and an enormous about of smart, capable talent on the beach. It’s a buyers market for banks or well-enough capitalized bigger brands in fintech.

And yet… all these headwinds are intrinsically temporary. AI, new payment rails, working open banking, digital-issuance continue to fuel huge new opportunities and usecases across verticals. The overall trend towards embedded finance is a powerful long term cyclical trend. As software continues to transform every industry, payments, capital and finance _needs_ to be more closely embedded in all the SaaS platforms, marketplaces and apps that business (and consumers) now use every day. Banks that take advantage of temporary market downturns to invest in embedded finance stand to benefit enormously through the next economic cycles.

Note: The following post is an elaboration on a recent advisory conversation I help with some institutional investors in the payments space. If you'd like to book me for a consultation or other engagement, check my offerings here.

Here’s the thing, practical, large scale deployments of AI have been used in payments fraud detection since the 1990s. In fact, payments fraud has long been seen as one of the obvious killer apps and ready-adopters for every stage of AI, from neural nets taking over from rules based systems in the 90s. Growth of ecom and attendant fraud, drove payments adoption of machine learning and supervised then unsupervised models through the 00’s, then deep learning and reinforcement learning through the 2020s.

So are large language models and generative AI just more of the same. Well, I think there is reason to argue that this time could be different.

a) Generative AI is not just for the good guys. Watch for a step function acceleration in the volume, effectiveness and new threat vectors for payments fraud. Especially smaller merchants, institutions and processors are going to be increasingly dependent on vendors to keep up in the arms race.

b) Generative AI is not just for the payments business. Businesses of all sizes stand to be benefiting from generative AI providing new value to almost all functions finance, ops, marketing, sales etc. But most mid to small size business will be buying solutions that integrate AI, and AI benefits from as much contextual data it can use and understand about the business. So advantage here to the ongoing super-trend integrated SaaS platforms like Shopify, Square, vertical platforms like Toast and platform-enablers like Stripe. Vs monoline providers like legacy PoS providers or legacy payments acquiring/processing.

Generative AI product opportunities in payment fraud detection

1. Pattern Recognition and Anomaly Detection: Large language models can be trained on transaction data to understand normal patterns and recognize anomalous transactions. I’d expect these improvements to be moderately incremental, not disruptive. But LLM ability to understand complex patterns could potentially allow them to identify sophisticated fraud strategies that simpler models might miss.
2. Synthetic Data Generation: Generative AI models can be used to create synthetic transaction data that mirrors the properties of real transaction data. This synthetic data can be used to train other machine learning models for fraud detection, particularly in cases where there may be limited examples of certain types of fraud. Actually, being able to test any code in fintech against realistic production data has always been a pain. Either you are potentially putting real sensitive PAI/PII info at risk or you just not testing realistically. Producing better synthetic test data for fintech could be a whole new product line or startup idea in itself.
3. Narrative Generation for Alerts: Large language models can generate detailed, understandable narratives describing why a particular transaction was flagged as potentially fraudulent. This could make it easier for human analysts to understand and act upon the alerts generated by the system. Why did your bank flag and just call you to confirm that ‘suspicious’ transaction? Maybe they don’t even know, gen AI could hypothetically help here with more specific and customized messaging both for internal testing/optimization or for improved customer communications.
4. Improved Phishing Detection: AI models could be used to analyze the text content of emails, SMS, or other communication channels to detect phishing attempts related to payment fraud. The models could be trained to recognize the subtle linguistic cues that indicate a message is a phishing attempt. Especially relevant when you consider how generative AI is also going to powering more sophisticated phishing in the hands of adversaries. This area is going to be a case of generative AI continuing to fuel an arms race on both sides of fraud. Possibly fraud/security and platform vendors here are really the only true winners in the long run.
5. Adaptive Fraud Strategies Detection: Large models seem to be surprisingly good at performing well even when pushed beyond their original training set. As fraud strategies constantly evolve, large language models with continual learning can adapt over time, understanding new tactics used by fraudsters and adjusting their detection mechanisms accordingly. Again, an important consideration when gen AI is also going to be helping the bad actors be more creative, productive and hypertargeted.
6. Multi-modal Fraud Detection: Combining text, transaction data, and potentially other types of data (like user behavior data), large language models can aid in creating a more comprehensive view of user activity and detect intricate fraudulent patterns more accurately.
7. Contextual Analysis: Generative AI models can help in understanding the contextual information around transactions. For example, they could analyze the text of a customer support chat to understand if a transaction was disputed by the customer, even if the dispute isn’t formally recorded in the transaction database.

More Adjacent Usecases and themes

1. Improving Customer Support and Interaction: Large language models can automate and enhance customer interactions, providing immediate, accurate responses to customer inquiries. This can expedite the resolution process for disputes and chargebacks, making the process more efficient for both the consumer and the merchant or bank. But would you buy a generative service just for payment/fraud related interactions? More likely, integrated platforms that combine payments with the rest of a business CRM might be the winners here.
2. Automating Evidence Collection: AI can help automate the process of gathering and analyzing data related to a dispute or chargeback. This can provide faster resolution times and more accurate outcomes, reducing the time and cost involved in handling these cases. This one again could be a whole new product or startup idea. Imagine an integration between gong (the SaaS that automatically captures and transcribes all cs/sales conversations) and Visa’s Verifi (a service that helps resolve disputes before or after they become chargebacks). Generative AI could be so good at resolving common disputes of what a sales agent allegedly promised vs what a customer received.
3. Predicting Disputes: AI models could potentially predict disputes and chargebacks based on transaction patterns, allowing for proactive measures to prevent or mitigate these cases. Maybe not a unique usecase for generative AI vs traditional ML/AI techniques. However, the increasing ease of access to models and custom training, could make all sorts of AI usecases easier to put in the hands of more users.
4. Tailored Resolution Strategies: Based on historical data and ongoing learning, AI could tailor dispute resolution strategies, ensuring that the most effective methods are used for each individual case.

The Threat Environment side of generative AI

1. Ever More Sophisticated Phishing Attacks: Large language models could be used to craft highly sophisticated phishing emails, text messages, or other communications that convincingly mimic the style of legitimate communications from banks, employees/bosses, friends or other trusted parties.
2. Impersonation: These models could be used to generate realistic chat or voice messages, potentially impersonating bank officials or customer service representatives, leading to social engineering attacks.
3. Data Mining: If given access to sensitive data, large language models could potentially be used to mine that data for personally identifiable information (PII), either to develop hyper-targeted attacks or defeat security questions based on personal information
4. Bypassing AI-Based Fraud Detection: If fraudsters can gain an understanding of how an AI-based fraud detection system works, they might be able to use large language models to generate transaction patterns that avoid detection.
5. Deepfakes: More advanced AI systems could potentially be used to create realistic video or audio ‘deepfakes’. While not a direct risk to the payment process itself, this could facilitate fraud or identity theft that could indirectly impact the payments industry.
6. Automated Hacking Attempts: Large language models, given their ability to understand and generate human-like text, could potentially be used to automate certain types of hacking attempts that rely on exploiting human vulnerabilities, such as password guessing or social engineering attacks.
7. A whole new generation of ‘script kids’: Generative AI is just very powerful at helping anyone learn to code and some models may be released or leaked without adequate (or any) safeguards around generating malicious applications