APIs and Integration Hubs: Highlights from the February Investment Forum Part 2

APIs and  Integration Hubs: Highlights from the February Investment Forum Part 2
This is the second of three posts bringing together selections from the great conversation at our February Investment Forum focusing on integrations, APIs, integration hubs, and app stores. The session featured expert panellists Matt Noble of Origo, Paul Richards of Fidelity Fundsnetwork, and Oliver Oehri of CSSP, NameYourSRI.com.
Origo has grown massively since I’ve been here and adoption has started to snowball which in itself is strong evidence for the build once, deploy many solution.
Matt Noble:

Firstly, let me concentrate on the positive part, and that is that it’s great to be working with Paul at the team at Fidelity, on various different services on the hub. And what this does by having somebody like Fidelity on is perhaps give evidence and reassurance to the retail platforms market that platforms are willing to work with us on this particular proposition rather than just, say, the life office platforms.

And looking at the pipeline of conversations for 2021, there are others that we’re having discussions with. And what this will do, if you look at the coverage of the integration hub right now, bearing in mind that when I started at Origo there were five or six contracted partners to the hub, we’re now on 37 I think it is, so a little over two and a half years we’ve grown from five or six to thirty seven. That in itself is good justification as to the belief in a build once, deploy to many solution.

If you look at the coverage granted, you would say, “oh, it’s slightly more weighted towards adviser software systems at the moment in that we’ve got more adviser software systems connected than the providers.” And also you’d say that “actually most of the provider coverage at the moment is the life office platforms rather than the platforms.”

As I say, that’s now starting to snowball and going back to the adoption rate, if you look at the some of the longer standing Origo services and solutions like the Origo transfer service that now powers 95 percent of all DC pension transfers in the UK, when we launched, it didn’t have 95 percent it powered let’s say 5, 10, 15 percent. But we’ve got to a point over 10 years where that is now the prevalent solution for  pension transfers. Don’t get me wrong,that task and that journey wasn’t an easy one.

That took a lot of hard work and conversations and proving that these services will work over time and allow the best route for things like integration. So I think knowing that we’re on a journey and the journey isn’t just a sort of a walk down to the end of the path, it’s actually all the way down to the end of the village and back again.

At the moment, contract enquiry is still required over bulk valuations because platforms don’t necessarily have all their legacy products sitting on them.
Matt Noble:

And then you start to think about going back to one of your points, around contract enquiry and legacy products and things like that. This raises a point around, is contract enquiry versus bulk valuations still a valid conversation? And the answer at the present moment is yes. Contract enquiry is still required over and above bulk valuations. And the reason being is that platforms don’t necessarily have all of their legacy products sitting on platforms.

Therefore, if they’ve had a historic contract enquiry service in the past that’s covered all the old legacy products, then therefore, until the point the platform puts all the products on the platform, it always still needs the contract enquiry. And then one last point just before we finish, and that is things like how we move into other areas with the integration hub and particularly protection.

There are some really exciting conversations that were inspired by Aviva, actually, I’ve just seen Tim Walton put his hand up and Tim was integral to that conversation. But there’s a sort of a question mark around how existing protection policies and the data that goes alongside those plans, how they can be replayed into back office systems and adviser software systems. So I can just see the use of the hub growing over time. But as I say, it’s not a short journey. It’s a journey that we have to go on as an industry.

For us, the end client view is quite joined up and everything can be seen in one place.
Paul Richards:

Which way are you addressing this? Are you addressing it from the adviser’s perspective or that of the client? Looking at where Fidelity are, we’ve got a workplace business, we’ve got a platform business that serves advisers, we’ve got an end consumer business. So the end client view is actually quite joined up. And I know this because I’m in Fidelity’s workplace scheme and I’ve got advised ISAs and pensions elsewhere and I can see it all in one place. So it’s not that that work isn’t being done. And where it’s more difficult, is to give the adviser a view of my other assets, for example.

So I have to go to my adviser and say I’ve got this, here’s the units, here’s the values. Can you incorporate that into your thinking, please? And that is not a good experience from my perspective. So I think it comes down to… I wouldn’t describe these as vested interests necessarily, it’s just businesses getting on with their own piece of work and thinking, right. There’s a great opportunity to grow the workplace here. And we can expand workplace into other investment vehicles and take a bigger piece of the overall client wallet without thinking through the implications of that.

As an advisory business, if you don’t have the Servicing Agent Rights for a client’s investments or pensions, it’s very difficult to get electronic data integrations through your back office systems. It can be very inefficient to go and get valuations of investments a client has from prior to working with you.
Matt Noble:

I think the challenge is around something called Servicing Agent Rights. And that very simply, as an advisory business, if you don’t have the Servicing Agent Rights for a client’s investment or pensions, then it’s massively difficult to get electronic data integrations through to your back office system without those Servicing Agent Rights.

So, if you put yourself in a situation, if you’re an adviser, you have a client, you’ve done for them seven or eight different investments or pensions in the past, you can quite happily get all of the data that you need typically for the back office from the platforms into your back office systems through the integrations, because you are the servicing agent for those plans. If they’ve then got some other investments or pensions that were done prior to you taking them as a client, then very simply, you will struggle to get an ongoing view on those on the valuations of those investments and pensions.

The only way that you can do it currently, really, is by repeatedly sending a Letter of Authority request over to those legacy product providers and saying, “can you give me a valuation?” And that’s just not an efficient way of doing it, because if you send one off in January, obviously the valuation has changed through the year. You have to then refresh it in June, or depending on how often you need to give sight to the client of these valuations.

So until either providers change the way that they can give data based on a client say-so or whether or not somebody like TISA can create a client ID that clients can then give to their advisers to say, “I’m giving you this client ID for the purpose of being able to obtain valuations based on you having this this client I.D.” So I don’t know whether or not that’s something that’s going to be happening soon or what.

With the advent of businesses creating their own APIs we had to take a more flexible approach. And when we build around a company’s API we can then help other firms integrate with them on the other side.
Matt Noble:

Without getting into the historics on it, just very briefly, the hub was essentially built as a starting point to use what was at that point called the Origo Standards. Since then, Origo has relinquished responsibility for running the standards and it’s run by Criterion. The Integration Hub was built based on what is now called the criterion standards. And it was very much our approach in the short term that we will build integrations based on the Criterion Standard.

And it became quite apparent that with the advent of businesses creating their own APIs that actually we had to take a bit more of a flexible approach. And our scenario now is that in order for us to grow the network of connected partners, actually we have to bend and flex. So in the scenario where Intelliflo has got an API set, Fidelity’s got an API set, whoever else might have got an API set,  what we do is we we look at those and we analyse them against what would typically work within the hub. And we can then do an exercise or a project where we transform or work with those APIs such that we make them work.

And what that does is looking at somebody like Intelliflo, it means that we’ve now built, I think three sets of APIs with with Intelliflo. Therefore we have experience of building against the Intelliflo APIs. So if a provider comes along and says “we’d like to connect it to Intelliflo, but we’ve looked at their APIs and actually, you know, we’ve assessed that it might take quite a long time.” We can stand up and say, well, we’ve already built three of them. We know exactly how they work, we can do all of the legwork for you.

So in that respect, and this is what I was saying right at the beginning, we’re not fazed by the fact that people have created their own APIs. Actually, it’s fine, because ultimately, if we’ve got to build against those, it just means that the community of people that they might want to connect to on the other side of the hub don’t have to go and do all of the API work. They just connect to the hub and again its a build once, deploy to many process.

So I think it’s really key just to stress that whilst we might have started off this journey with a very strict approach of ‘this is how you build against the hub’, we’ve made a decision that actually we’ll flex, we’ll bend, we want this service to grow across the industry. In order to do that, we need to take a more pragmatic approach.

We went through a multi-step process to put together the App Store. We also spent a lot of time looking at sustainability and customer experience.

Keeping up with ESG regulations is a dynamic process.

Oliver Oehri:

Maybe I start a little bit for the journey of how you build this App Store and then make the idea what the App Store then can for TCFD and SFDR, because maybe there are also people in the line who have thought about doing the same for just for all the data. And maybe it makes sense to see what is the architecture behind that. And if you go for such a journey, we when we started 10 years ago, we more or less had four stepping stones for ideas we had to look at. And the first was data access.

And if you go for this topic of sustainability, it’s quite difficult because you have not only financial data like full holdings of funds or other stuff, you have so-called non-financial data and the usual suspects to identify and that 10 years ago was quite critical because there were so many of them. Nowadays we have it more easily because you have more or less five to 10 ESG data providers, which you really can count on and I think most of the half of it we have on the contract just have names. MSCI, ESG, CDP, something like that. Then you have to look on the workflow of the data integration process.

And if you have a traditional data process, you just go to the data providers, buy the annual license often quite high with the price, and then you have to use it. And you don’t need a big store for just calculating a sum of some data. So that’s the idea, what you really need. And then you have to look at the user experience. And then we asked ourselves, “what do advisers really need? Do they really need data or is it just they want to have a ready to use analysis?” And the best thing would be to have that in a format as a report they can also send to their clients. And then INVR on your question, SFDR, TCFD.

Let’s start with SFDR, because that’s I always call it, it’s the monster of regulation we are facing at the moment. So for all those who are not only UK and probably also SFDR are coming sometimes into UK. SFDR is the combination of all possible estate, the ESG data models you can have at the moment. And the hard thing is it starts quite easy in March with a self declaration, which is easy to go. Just you have to make only two questions.

Yes or no? No means you are not ESG or not a ESG data driven product that’s Ortec. Six for SFDR and yes means you have an ESG process in line like ESG integration, which probably a lot of asset managers communicated in the last two years that they have integrated the ESG so that completely every product Article 8 and Article 9 is if you have a clear objective, a clear achievement on the ESG, that’s the so-called impact or sustainability front more or less.

Now, the hard thing is starting at the end of this year. The regulation on SFDR says if you have self declared as an Article 8 and 9 product, you have to start on a periodical report on your products, on ESG data. And that means ESG as well, carbon data. Coming to TCFD in one minute. And then now it’s getting the horrible thing after one year more, so at the end of 2022.

You have to bring also transition data to the table as well as SDG and adverse impact data. If you haven’t heard that, transition data means you have to compare your product to a one point degree portfolio pass. That means Paris alignment. So it’s your climate benchmark one point five comparable to your product. That means you have to make forward looking indicators on carbon in your product, quite hard to do.

And the nice thing or the hard thing is that we have at the moment five different scientific target methodologies to make that one point five degree portfolio. And it’s not sure what we have to take. And adverse impact or something like green and brown share, energy consumption, all the nice stuff.

And the consultation is dynamic. So each week, really, literally each week, there are changes. So what we do in FEfundinfo, we built what we think as a scenario could be probably in the next two weeks and adapt it over the next two years like a best practise guarantee of regulation and make that on the automatic way. So customers just have this SFDR regulation now to make that easy.

That was by a start, SFDR. TCFD is just the carbon site on SFDR, so you have to have carbon emissions in your TCFD reporting, which means scope one, scope two, scope three emissions can make here a lecture what it means scope one and two. Have in mind a Range Rover production company and the factory would be scope one, the electricity or energy you have to consume for that Range Rover, is scope two and the value chain before and after is scope three.

So scope three means Range Rover drivers around the UK, what is the CO2 emission they produced? So have that in mind. That’s the target line for TCFD, hard to do it. And that all the parties transition that means the Paris agreement, the portfolio past comparison. So TCFD means carbon focused back as well as forward looking indicators and SFDR, horrible thing, is TCFD plus ESG, SDGs as well as impact adverse principal data and that’s is coming at the moment.

About The Author

Emma Iskowitz

Originally from New Jersey, Emma previously worked as a writer, researcher, content creator and podcast producer for fintech consulting firm Ezra Group LLC. Emma graduated from London Contemporary Dance School in July 2020, and alongside her work at FTRC she is also pursuing a career in contemporary dance.

Leave a reply

Your email address will not be published. Required fields are marked *

Register for updates


Highlights from:

We use cookies to track usage of our website using Google Analytics. Click here to opt-out.