4 ms·

API Routing Layers in financial services

37 points by kunle 6y ago

Jpoliachik 6y ago
Lots of niche areas for disruption throughout this entire Fintech stack.
- kunle 6y ago
  Yep. Also as more services become available doing variants of the same thing, very likely it will be easier to bulid a layer on top to make it easy to access all of them
scribu 6y ago
I'm curious how these aggregators (i.e. API routing layers) convince vendors to work with them. Is it just the promise of high transaction volume? For Segment it was relative easy, I imagine, because most of the tools they integrated with had freely-available APIs.
- kunle 6y ago
  In a lot of cases they don't want to deal with a small startup in the first place, and the aggregator is paying full freight anyway, so the vendors are happy to do it.
- tomasien 6y ago
  The key - for us - is to be not just a routing layer, but a huge value add in addition to being a routing layer. We provide workflow management, decisioning, analytics, etc and those are things that all clients need. Underlying providers of various things know they will need to be integrated into something like that (whether homegrown or built by a vendor), so being part of an ecosystem like ours that ensures success is critical. Homegrown implementations of the same vendors vs. using those vendors in Alloy stops less fraud, causes more manual work, is more opaque, approves fewer good customers, takes longer to get live with, etc. Importantly, we don't pitch either side (vendors or our clients) on using Alloy to compare vendors - rather to make the most of them (now and as their needs change). It's not just "I can switch this at any point" it's "I will have a best in class system now and the peace of mind that I will have a best in class system tomorrow as my needs change, without needing to engage in 5 enterprise sales cycles to get there"
RileyJames 6y ago
During my time at Xero we pushed back quite hard against partners (not individual customers/users) using aggregators / api routing layers for a few reasons. The biggest issue was quality of integration/product. When a partner wanted to use an aggregator, that became the limiting factor for their integration, ie: I'm going to build this integration once for Xero/Quickbooks/MYOB/others using AggregatorX so it's only going to support features which exist within AggregatorX, which will limit the integration to features which every product has, and which operate in a similar enough way that they can be supported by AggregatorX. Now, that might be fine for an end customer, which is just trying to create an invoice and get a payment on it, and may switch accounting systems in the future. (this again depends on use case. I would argue that in most cases if you want to get the most out of Xero + Internal Application, you're bottleneck will become what the aggregator enables) But if you're using an aggregator style product to integrate, say Shopify & Accounting (Xero,QB,etc), it's ultimately going to piss everyone off, except maybe the product manager who can tick off Xero,QB,MYOB,Freshbooks,etc in one sprint. The business team who pushed this integration to be built will be disappointed because there is no differentiation in the integration to each product. The dev teams are disappointed because the specific product features they built that they believe (rightly or wrongly) are better than the competitor, are glossed over because they can't be easily aggregated into a generic workflow. And end users / customers are disappointed because the features they like about Xero/Quickbooks don't seem to work when integrated with Shopify (example only). There may be a place for aggregators, but they need to align with the interests of the parties behind the integration. Making the integration easy for the dev team is great, but not at the expense of the purpose of the integration for the customer, the product and the business.
- tomasien 6y ago
  I think this is a great point. A routing layer on top of a deeply feature rich set of underlying providers is probably not a good idea. I think that's why API Gateways are kind of "meh" I think routing layers need to be super thoughtful about this. How will I architect my system to ensure this isn't the case? Or doesn't matter? Or just doesn't happen?

37 points by kunle 6y ago

Jpoliachik 6y ago

Lots of niche areas for disruption throughout this entire Fintech stack.

kunle 6y ago
Yep. Also as more services become available doing variants of the same thing, very likely it will be easier to bulid a layer on top to make it easy to access all of them

scribu 6y ago

I'm curious how these aggregators (i.e. API routing layers) convince vendors to work with them. Is it just the promise of high transaction volume? For Segment it was relative easy, I imagine, because most of the tools they integrated with had freely-available APIs.

kunle 6y ago
In a lot of cases they don't want to deal with a small startup in the first place, and the aggregator is paying full freight anyway, so the vendors are happy to do it.
tomasien 6y ago
The key - for us - is to be not just a routing layer, but a huge value add in addition to being a routing layer. We provide workflow management, decisioning, analytics, etc and those are things that all clients need. Underlying providers of various things know they will need to be integrated into something like that (whether homegrown or built by a vendor), so being part of an ecosystem like ours that ensures success is critical. Homegrown implementations of the same vendors vs. using those vendors in Alloy stops less fraud, causes more manual work, is more opaque, approves fewer good customers, takes longer to get live with, etc. Importantly, we don't pitch either side (vendors or our clients) on using Alloy to compare vendors - rather to make the most of them (now and as their needs change). It's not just "I can switch this at any point" it's "I will have a best in class system now and the peace of mind that I will have a best in class system tomorrow as my needs change, without needing to engage in 5 enterprise sales cycles to get there"

RileyJames 6y ago

During my time at Xero we pushed back quite hard against partners (not individual customers/users) using aggregators / api routing layers for a few reasons. The biggest issue was quality of integration/product. When a partner wanted to use an aggregator, that became the limiting factor for their integration, ie: I'm going to build this integration once for Xero/Quickbooks/MYOB/others using AggregatorX so it's only going to support features which exist within AggregatorX, which will limit the integration to features which every product has, and which operate in a similar enough way that they can be supported by AggregatorX. Now, that might be fine for an end customer, which is just trying to create an invoice and get a payment on it, and may switch accounting systems in the future. (this again depends on use case. I would argue that in most cases if you want to get the most out of Xero + Internal Application, you're bottleneck will become what the aggregator enables) But if you're using an aggregator style product to integrate, say Shopify & Accounting (Xero,QB,etc), it's ultimately going to piss everyone off, except maybe the product manager who can tick off Xero,QB,MYOB,Freshbooks,etc in one sprint. The business team who pushed this integration to be built will be disappointed because there is no differentiation in the integration to each product. The dev teams are disappointed because the specific product features they built that they believe (rightly or wrongly) are better than the competitor, are glossed over because they can't be easily aggregated into a generic workflow. And end users / customers are disappointed because the features they like about Xero/Quickbooks don't seem to work when integrated with Shopify (example only). There may be a place for aggregators, but they need to align with the interests of the parties behind the integration. Making the integration easy for the dev team is great, but not at the expense of the purpose of the integration for the customer, the product and the business.

tomasien 6y ago
I think this is a great point. A routing layer on top of a deeply feature rich set of underlying providers is probably not a good idea. I think that's why API Gateways are kind of "meh" I think routing layers need to be super thoughtful about this. How will I architect my system to ensure this isn't the case? Or doesn't matter? Or just doesn't happen?