Insights from New York Fintech Week 2024


It’s a sign of strong conference content when you are constantly wish you could be in every conversation track at the same time. Thanks to Empire Startups for putting together a stacked program for this year’s Empire Fintech Conference as part of New York Fintech Week 2024.

It’s time for new cores and foundations

It’s amazing how far we’ve managed to get with digital-first banking and payments as well as embedded finance in the last several years, given the core systems tech that underpins it all. But between the rash of compliance actions, and the inevitable continued growth of AI and real-time services, it’s time to re-invest in the core. It’s going to take time and investment, but our institutions need move to systems that can act and settle in real-time vs batch, that properly support multi-tenant distribution partnerships with fintechs, that carry richer data with every transaction. And do all of the above with reliability, observability and enable scalable compliance and risk-management solutions for every more complex and faster-moving ecosystems.

It’s time for a third act in BaaS (Banking as a service)

American Bank regulators are cracking down on laissez-faire operational models of renting bank licenses to fintechs. For banks this all means there no more ‘easy button’ using fintech channels to grow ‘free’ balances, and no outsourcing compliance/risk policies to fintechs or middleware intermediaries. For Fintechs, it means it’s going to be harder to find bank partners, and you are going to need a more direct relationship. The original sin here, was hacking legacy bank that were never built for multi-tenant fintech usecases and not for the scale and growth of fintech usecases. Think: fintechs suddenly growing to handle millions of realtime ledger transactions per day, then trying to settle and reconcile all those transactions to 2-3 ‘real’ bank end bank accounts. Once per day. Manually. In batch more. You can understand the scaling problems. The path forward: Besides re-investments in core systems, direct relationships and stronger oversight between Banks and Fintechs. For better or worse, we’re also getting more clarity on regulatory expectations. Short term pains for more durable, reliable and compliant frameworks going forward.

Soon, real open Banking for the US?

The clock is ticking.CFPB Section 1033 is coming to officially open up Bank Data in the US. The big provisions give consumers right to access and share their bank data with 3rd parties. In principle consumers should also finally get important data privacy rights to prevent some of the shadier side of wholesale data brokering. But as these things go, the initial version still leaves much to be desired. Overzealous in some areas and too narrow in others. The biggest gap is that only narrowly-defined consumer banking data is being opened up, businesses are left out so are wealth management accounts, mortgages and more. Ironically, those are also the categories where there’s probably the most value to be created with open banking tools. Nonetheless both incumbents and fintechs need to be preparing. New strategic risks and operational challenges definitely await, but so do significant new business model opportunities.

Of course AI, but not exactly ChatGPT

It’s turning out that the killer app for AI in financial services is… a lot of different kinds of AI, ML and sometimes LLM models, but more narrowly scoped and specifically trained to solve specific tasks or workflow steps, vs a big generalized AI being the whole product. Also typically AI in support of human processes vs being directly customer facing. A lot of talk of AI underwriting, claims adjusting, payment dispute handling or AI tax/wealth advisory etc.. But for now the killer app for AI is in just parsing and organizing all the inputs vs replacing any critical decision making. At least until multi-modal models, more observable models, models that do better at math etc. can be more easily combined and trusted. (so give that just another 18 months or so?…)

The investment opportunities are still out there

Look for where value is high but NPS scores are low. We heard about fintechs finding their wedge by fixing 401k rollover experience, digitizing wills and estate planning, the car financing and underwriting experience, using open banking to intelligently schedule payments to avoid overdrafts, and many more

Personal Bonus

PS. special mention to Skipify carrying forward the torch for easier/faster checkout across the web. Now with a Visa Click to Pay partnership they are now both figuratively as well as literally the spiritual successor to my own baby, the Visa Checkout wallet. Go Skipify!

Posted in finance, fintech | Tagged | Leave a comment

Could the recent concession on interchange actually be a boon the card networks?

2w •

There’s a way of thinking about the job that interchange fees actually are. The bulk of interchange fees flow back to cardholders in the form of rewards (particularly points or cashback on purchases) as well as general card features and benefits. In practical terms, cards function as a way for consumers to collectivize and demand certain discounts from sellers, proportionate to the spending power they represent.

On the merchant side, accepting cards has always helped to benefit top-line due to consumers higher propensity to spend on card as well as other benefits of convenience, operational efficiency and trust etc. But of course there’s a limit to how much those acceptance benefits weigh against the cost of swipe fees. All else being equal, any rational business would prefer to take less of a merchant discount rate if they could. This merchant calculus varies significantly across segments. But universally, acceptance volume is sensitive to payment costs.

For their part, the networks have long been stuck in sort of prisoner’s dilemma. Networks depend on not letting average interchange drift too high. But when effective rates get too high, card acceptance wanes, merchants push back, competing rails or close-loop schemes emerge, or regulators step in. And so the card networks struggle with trying to keep their merchant constituents happy enough while also keeping their share of issuance. Issuers are constantly playing Visa and MasterCard off each other for higher rates, or looser rules on qualifying various portfolios for premium rates. The issuers have to constantly push on interchange fees to compete against each other on rewards offers – even to the existential risk of the industry’s whole golden goose.

And that’s why this week’s settlement news (btwn MC, Visa and US merchants) is a potentially big win for the US card industry. If you haven’t already, read the whole details below. The merchants get a win, it’s not huge, but a 4-7bps savings in fees, locked in over several years is something. At the same time, those cuts should not materially impact rewards programs so consumers still win. For the networks and the banks though, a negotiated cap on rates helps break the prisoners dilemma of upward pressure on interchange. They can’t say it out loud, but many a network exec are probably breathing a sigh of relief that rates are correcting (slightly) downwards.

Lastly, the settlement potentially takes some of the heat off of Durbin2.0 and the likely industry carnage if the CCA act passed. In the meantime though, networks and issuers are just going to have to rely on actual innovation and delivering new value to compete instead of just on rates.

Posted in Uncategorized | Tagged , , , , | Leave a comment

Dieter Rams’ 10 principles of SaaS API design

For those of you who’ve spent time at design school, or even just walked past the halls of one, you’ve probably heard of Dieter Ram’s 10 principles of industrial design. For anyone who’s spent the odd decade or two building online and SaaS products, you’ve undoubtedly mediated a good many engineering debates on software design best practices. Engineers too, have their own lexicon of deep lexicon and idiomatic principles of software design.

Product leaders, you sometimes can’t help making a few cross-disciplinary conceptual connections. I’m not sure if old Dieter (who’s still kicking btw) has ever spec’d out, say, a payments API, but if he had…

Dieter Rams’ Design Principles
Core Principles Good API design
Good Design Makes a Product Useful – A good product must have utility and always balance form with function.

Before all other considerations, firstly your API has to do something useful. I like to say, an API is just a messenger. Don’t shoot the messenger if the real problem you have is that you haven’t yet built some useful services the world needs to be served over an API. Then to make that service useful, the API needs to offer the right granularity, call sequencing and inputs/outputs that at least minimally enables the solutions your customer will want to build.

If you’re having difficulty getting customers to integrate your API (or any new product), usefulness is the  assumption you really need to validate first – before assuming any other aesthetic re-working will solve your problems.

Good Design Is Innovative
The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design.
Innovative design always develops in tandem with innovative technology, and design can never be an end in itself


Great SaaS APIs unlock your customer’s ability to innovate, by being really good at one thing, so they don’t have to be. Innovation is cumulative, and engineering advances through useful layers of abstraction. Every good API a little giant for others to stand upon. Innovation also means differentiation, and avoiding commoditization. If there are many others already like it, what new value are you creating?

Conversely, good APIs are not led by Resume-Driven-Development. Be careful of the occasional impulse to leap upon new fashionable platform/language/frameworks etc as and end in itself.

Good Design Is Aesthetic – The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being..

An aesthetic API picks a clear, readable, self-documenting style and is consistent. An elegant software design avoids ugly quirks or hacks to be effective.

A good API will steer (and not arbitrarily restrict) API users from making good design choices in their implementations. Aesthetic, UX tested reference apps or implementations can go a long way to set a bar or exceptions and help implementers make good choices. All of which will ultimately best improve changes success with end users and adoption.

If all else fails, just make sure your developer-docs site has a cool chill-wave vibe and renders well when viewed in ‘dark mode’.

Good Design Makes a Product Understandable – Good design leverages affordances, it can make the product clearly express its function by making use of the user’s intuition.

Good APIs are well documented. Starting with having accessible (preferably public) documentation. And that the API’s behavior actually matches what’s in the documentation and the examples (Sounds obvious, but surprisingly hard in practice to maintain). Good APIs themselves should be self describing as reasonably possible. Sure, ‘naming things’ is known as one of the Hard Problems in computer science. Nonetheless, endpoints, methods, parameters, and returned results should strive to use intuitive names that convey their purpose and functionality.

Following familiar conventions (like standard REST and JSON) makes APIS understandable and reduces the learning burden on developers. Consistency is Key across your API products, rather than forcing developers to relearn different idiomatic patterns arbitrarily. Next best practices are having language-specific examples, ‘recipes’ for different solutions, SDKs if applicable, mock/sample apps to demo and test capabilities.

Good Design Is Unobtrusive – Neutral, allows user expression.

One of the main reasons we build APIs as abstraction layers to our backends is to give flexibility to the front end implementation. A non-leaky abstraction is unobtrusive. A good API doesn’t force awkward or unnecessarily restrictive design choices for the front end. Good APIs can be opinionated about proper useage,  Minimizing  foot-guns and generally making it harder to use the API poorly. The art though is an inevitable tension between designing an API that is broad enough to support many use cases but exposes excessive complexity, data and surface area than is strictly needed for any one use case. Vs trying and failing to create a perfectly scoped API that becomes too narrow or restrictive to  support some important but newly discovered use case.

What I love best, is to design a clean set of versatile primitives. Each service simple on their own, but composable and flexible to serve diverse customer segments, usecases and solution types.

Good Design Is Honest – Truthful about product capability.

The Principle of Least Surprise:  Software should behave in a way that is least surprising or astonishing to its users. In terms of capabilities and performance, this means that a system should accurately represent what it can and cannot do, and how well it performs. 

Be up front about Beta vs GA readiness of your service.  You’d be surprised how much less concerned your customers are about absolute levels of uptime, performance, bugs vs what they experience relative to the initial expectations you set.

Good Design Is Long-Lasting – Avoids being outdated quickly. It avoids being fashionable and therefore never appears antiquated.

Extensible and Maintainable – Designing and launching some new feature is like the exciting ‘kitten’ phase of software ownership. But remember, the real cost is that, that you could now be on the hook for feeding and changing the litter box on this once-cute feature for years more to come.  Software must always be maintained, patched and supported. And you need to build with that in mind. Similar to durability, Throw-away work and tech debt happen, but try to be intentional vs accidental about it. You often end up living with those choices longer that originally imagined.

Don’t break your Customers – Allow your customers’ investments in your service to be as durable as reasonably possible. Good APIs should be extensible without breaking or requiring onerous re-integration and re-testing by existing users. New features should be optional rather than required, and existing users should see forced version updates rarely as possible. (protip: But maybe also include some contractual sticks/carrots to keep your customers from forcing you to support legacy versions beyond all reason 🙂

Good Design Is Thorough – Care in every detail. Robustness Principle or Postel’s Law: “Be conservative in what you send, be liberal in what you accept”. This means an API or data system should strive to be as accepting as possible of the input data it receives (while still ensuring security), and follow standards strictly when sending data or communicating outward.

Errors and Exception Handling Matters: Sweat these details in the requirements. Your API should provide meaningful error messages that help developers understand what went wrong when a request fails. A lazy API spec focuses only the happy path, leaving  other paths as ambiguous or undefined.
Good Design Is Environmentally Friendly – Conserves resources, does not deliberately or incidentally externalize costs and harms.

Literally environmentally friendly – not wasteful in use of resources, including memory, CPU cycles, and bandwidth. Both benefiting infrastructure costs of scaling and direct environmental impact of energy use.

Mindful of the Compliance, Security, Privacy Environment -  For example, a mindful API doesn’t ask for, nor return any private data not strictly needed for the usecase, and adequately protects any private data that is.

The digital, social and economic environment – a responsible API designer would not single-mindedly help drive-up online clicks and engagement, but while also incidentally undermining western liberal democracies in the process.  

Good Design Is as Little Design as Possible – Purity & simplicity.

The ideal API asks for only what it needs, and returns only exactly what is needful

Similarly, a nice API is not overly chatty, requiring more round trips (each round trip adds more latency, more resources, more things to code and debug) than should be necessary.

Of course, easier said than done. Rare to get the above perfectly right on the first release of an API spec, nor is it even reasonable (or desirable) to necessarily predict all future use cases for your web service. Nonetheless, ‘as simple as possible, but no simpler’ is an important ideal. Versatility and flexibility are also valuable, but I always like to think of anything that drives complexity, as a budget to spend carefully and to continually re-evaluate.

Generally, the less complexity you need to effectively get a job done, also creates less surface area you’ll have later for bugs, exploits and maintainability. The less complexity debt you assume now, the faster you’ll be able to iterate and innovate on your product in the future


Posted in Product Management | Leave a comment