
API Routing Layers in financial services - kunle
https://kunle.app/may-2020-API-routing-layers.html
======
RileyJames
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
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?

------
scribu
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.

~~~
tomasien
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"

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

~~~
kunle
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

