API compliance and risk: Why traditional approaches may fail
This is a risk and compliance based guest blog by Northey Point associate Mark Rodgers. For more information visit: Regulatory and Compliance Corner.
Gone are the days (not too long ago) when APIs existed only in old fusty back office systems, yanked out of their electronic cages when called on (literally) to prove some important internal IT development and to assess customer impact on special data such as reference data change.
Wheel forward to 2019 and we find the API explosion in the middle of the current digital technological speedway. Indeed in 2019 there has been a greater rate of growth in new APIs than in all previous years, and demand for access to valuable content is by millions of users making billions of calls using APIs to conduit them to reveal and devour the data they want and need (Google at least 5 billion per day and Twitter 13 billion Source: internet / elasticpath.com).
No surprise then that range of uses that APIs are put to today is wider than ever and increasing with developers seeking to speed up the promotion and adoption of APIs to monetize and create revenue growth.
No surprise too that compliance , risk management functions are at the forefront there to keep us all safe and well serviced, and regulators to look over APIs / API use.
Financial services and payments is no exception to these trends whether for example the API use enables institutions access to participate into the UK national central payment infrastructure or that it enables a newly authorised e-money issuer to set up e-money accounts making payments, or a retailer card lender using APIs to enable purchases from a range of partnering online retailers and access data to determine credit limits. These a but a tiny fraction of API enabling uses.
But how broadly does risk and compliance fit into this fast expansion of APIs / API use?
Overall regulation has needed to adapt and catch up with API proliferation, resulting in a regulatory landscape change with far greater complexity of different layers covering different regulatory regimes and all over the same API territory. Furthermore, there are greater numbers of and tighter interlinking regulatory requirements to existing traditional conduct of business requirements, financial crime and the general UK legislative legal framework all of which remain to be complied with.
A case in point is enhancement of consumer protection and encouragement of competition via PSD2. Take secure customer authentification. In addition to existing FCA conduct of business requirements and anti-money laundering legislative compliance there are also EBA Guidelines on ICT security risk management and Regulatory Technical Standards implementing PSD requirements. Included too are the recent FCA guidelines on operational resilience.
There have always been a range of different regulatory requirements but with APIs there is a also a commensurate large technological shift. The need for great compliance understanding and demonstration across wider discipline is never greater with APIs. Not forgetting we must also not forget pivotal need to comply with API creation standards even before use ( Governmental or within Open-Banking standards ).
The implications for firms to demonstrate compliance are profound, stretching and changing what response is required to achieve compliance. Organisational structures are a starting point because where more traditional structures are employed they are often accompanied by traditional compliance functional processes and procedures which may in themselves be fine with well worn routines working well with older systems and processes.
API’s now and their centrality in all points of the customer, products and servicing lifecycles require a different non-traditional skillsets and a new type of compliance officer ( compliance team?) in both an advisory and assurance compliance contexts. We are speaking of the breadth of skillsets required which need to be very wide enough to cope with the demands of assuring compliance across APIs and moreover their use.
The potential dimensions are in some way Oceanic be they competition , conduct, security and or operational compliance requirements or ISO standards to IT infrastructure for IT network security and resilience whether networks are de-centralised or not.
In the event the number of relevantly skilled and experienced staff will be limited and it will be a while before this ‘rangey’ compliance segment of the UK population acquire requisite skills and knowledge.
Organisational structure is a relevant too, thinking about the range of operating models firms adopt and which present compliance functions with another discipline to master. Outsourcing isn’t new in regulatory terms it is true but supplier management compliance oversight requires another quite unique skillset and knowledge of third party compliance and risk in both a contractual and direct regulatory sense.
Many firms then adopt models where APIs are outsourcers because of where and how they fit in the digital value chain such as helping you to connect your network and how your customers will be able to use your services. All this provided not in-house but outsourced often hosted in the cloud and so yet another mode of business operation requiring wider compliance and skills lined with technology risk knowledge that was previously only in the domain of IT / security professionals.
These skills and knowledge gaps points to several and it is accepted there is no one fits all responses. First upskill all compliance staff in across all dimensions which will take time and a prolonged programme of training supplemented with extensive development immersion into all relevant parts of the business / operations.
Or, do you look at the possible different functional response or configuration which itself may bring into question whether a compliance function at all per se is still the relevant function and does compliance need to morph itself to be more akin to risk functions which is an approach that some firms take?
Point at hand is that we arrive where an alternative to look for a new order of compliance function and compliance officers. We are at a cross roads where compliance must evolve to embrace compliance across wider risk types that a pure regulatory risk types to manage API compliance.
At the same time we must maintain the existing compliance knowledge and experience, as per well established routines and frameworks about the impacts of use of APIs, which are rooted in existing regulatory standards and sourcebooks and which speak to what regulated activities your firm does (what you are in business for).
This is a risk and compliance based guest blog by Northey Point associate Mark Rodgers. For more information visit: Regulatory and Compliance Corner.
Read, subscribe and share
This is the first RC Corner blog by Mark Rodgers, further blogs will follow.
To receive insights into payments in the UK, subscribe to the “Payments, Payments,Payments” newsletter.