Open Banking PTBR

Don't know 6.7% Are you using an API definition language? (N=60) Do you use any API lifecycle tools? (N=41) RAML 3.3% 60% Open API/Swagger Postman API Science APImatic API Metrics Runscope Parasoft SmartBear Stoplight 2 Restlet Other 0 10 20 30 API Blueprint 16.9% 11-50 16.9% GitHub 6.7% WSDL 6.7% API architectures within banks are incredibly complex, with a quarter (25.8%) of survey respondents calculating they have more than 500 internal services. The majority of those services are not yet API-based, although there is clearly some reorientation: 33.8% of survey respondents indicated that more than 100 of their internal services are API based (out of the 45.5% that have more than 100 internal services). While many banks commenced an IT modernization strategy several years ago, the majority of those interviewed have indicated they feel they are still only "half way through" the process. This is evident in the similar number of large SOAP and REST APIs within banking systems, although the transition from SOAP to REST is also evident: a third (33.9%) of respondents said they no longer have any SOAP APIs, compared with 7.9% who have no REST APIs. Reflecting the current legacy transition from SOAP to REST, 6.7% of survey respondents are using WSDL files to define their APIs, while open APIs, API Blueprint and RAmL are used to define APIs amongst 70% of survey respondents. The Open API Initiative (OAI) is clearly becoming the new standard amongst banks looking to use an API specification format and will be essential to the success of open banking ecosystems, as the specification allows third party and partner developers to quickly understand the capabilities of a bank's APIs and integrate it into their products and services. The OAI specification creates a new way of standardizing the Banking API Stack around a unified API description format, and enables more open banking API tools to be created; for example, the recent OAI PSD2 verifier and the OpenID Connect OAI verifier. There is a low level of usage of API lifecycle tools indicated by both survey respondents and in banking interviews. The majority of bank interviewees indicated they either use their own internally built tools to create APIs, or the API team does not prescribe tooling for lines of business to use when departmental teams build APIs, instead focusing on creating style sheets, and standard libraries that teams are encouraged (but often not obligated) to use. "We already started some years ago to modernize our infrastructure, and now that is being driven by the regulation. We have an ESB and SOA internal architecture that we are moving towards a microservices architecture approach. We have containerization, microservices running on cloud, and DevOps approaches. We think open APIs have to be REST APIs, but we have a big core banking system. Most banks are based on the mainframe, so we all have a lot of legacy: it is about how to decouple what we need to do. We often have to have SOAP-based interfaces and then consume them via an open API gateway," described one banking executive, mirroring several other comments received during interviews. 21 The new BanKIng STacK

• Cover