Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
The pressure for banks to “open up” is increasing from two directions: market trends from Fintech add further demands while regulation and standardisation efforts, most prominently PSD2/XS2A and the global push towards real-time payments, introduce a range of requirements to be met in the future.
As consumers and corporates move towards engaging with banks’ services through a range of mobile, tablet and web apps, the banking sector is facing one of its biggest revolutions in decades. A challenge that comes with great business opportunities: the quick introduction of leading-edge APIs, aided by rapid development and testing tools, allows to establish new business and to focus on customer benefit and cost-efficient adaptation.
The ongoing API revolution is commonly assumed to change the role of banks beyond the provision of core bank services to the operation and management of access platforms; major investments that should be seen as an opportunity for new monetisation models. While the future customer experience is increasingly being shaped by Fintech platforms and apps—operated by banks, their partners or third parties—the interface between customer-facing applications and core bank services will remain with the banks.
Support for any stage of API establishment
Rolling out an API programme consists of four major phases for a bank:
- Exploration of business and technical options,
- Implementation, by defining APIs, building their end points and connecting to the bank’s systems,
- Testing of the APIs, and
- Launching the service taking account of customer onboarding and support needs.
The XMLdation cloud platform assists banks throughout the API development life cycle. It enables rapid prototyping from the earliest exploration stages and assists in establishing implementation guides as the APIs are defined. Mock API servers (a replacement version behaving similar to the real API, including validation and simulated reponses) and the automated provision of test data turbocharge testing efforts. The self-service onboarding portal and API sandbox are cost-efficient means to reach customers with the best possible support during launch.
Exploration: Early API Sandboxes
As banks explore the business and technical aspects of their API programme (technology selection, migration strategy etc.), XMLdation experts contribute their knowledge of XML banking interfaces, RESTful APIs and upcoming banking API standards, in combination with a review of the bank’s technical interfaces to rapidly build a matching “standalone” API sandbox. Teams can interact, play with, and review the APIs in expert-led workshops, allowing to iteratively innovate around the business and technical possibilities.
Rapid API prototyping helps business and other stakeholders establish a more concrete understanding of the APIs and their potential. It enables the early validation of API plans with customers and developers as well as the exploration of potential technical issues before the implementation phase.
Implementation: API implementation guides
Moving on to the implementation phase, the APIs need to be built, connected to back-end bank services, and secured.. In this phase, XMLdation can assist banks with the API definition using an efficient and methodical approach: refining the API syntax e.g. using the world’s most popular API framework OpenAPI/Swagger, expressing the business rules and generating API implementation guide documents. Online collaterals, e.g. wiki pages, are created and example API requests generated. The early API Sandbox prepared during the exploration phase can easily be updated to reflect the agreed API definition.
If desired, a SaaS collaboration environment for teams to manage API definitions themselves is provided by XMLdation’s message management service myXML: this allows making API changes available to developers promptly, while at the same time serving as a centralised collaborative hub, knowledge base, and documentation source within the organisation.
Centralising the implementation phase in XMLdation’s cloud-based specification hub simplifies internal processes and reduces risks, as the API is well defined and understood by all stakeholders. This way, the API will be aligned with banking API standards and best practices.
Testing: Mock APIs and auto-generated test data
Once in place, APIs have to be tested. Testing needs to cover a whole range of concerns e.g. end-to-end testing, effective handling of erroneous data, load testing, security testing, and response times. In this phase, XMLdation assists banks by providing mock APIs for use in end-to-end testing, and by providing auto-generated test data.
In end-to-end testing, a number of APIs are usually required to test the entire flow. For example, an API to request account balance may be called followed by a credit transfer API request. A common complication in test efforts, and one that can delay testing efforts significantly, is that API implementations do not all become available at the same time because of different project timelines. XMLdation services enable the creation of a mock API, based on the API definition and sharing much of the same functionality available within the API sandbox. The mock API provides validation and simulated responses and can be used in the cloud or by deploying it into a test environment as a downloadable application. This way, end-to-end testing can be carried out, even while some of the API implementations have not been delivered.
Banks may also create comprehensive sets of test messages for testing their APIs with large volumes of transactions, as XMLdation further provides the most thorough test file generation in the market: building on broad knowledge of banking interfaces, along with bank data (IBANs etc.) and small sets of (example) customer data, the API definition prepared in the implementation phase is used to automatically generate a broad range of test data (API requests and responses); this data can be downloaded or is provided through an API that allows test frameworks iterative access.
Herein, the cloud service is able to create test data of unprecedented depth in an instant, tailored with real content, up-to-date timestamps and more. Data generated covers pass and fail cases for all business rules, as well as fail cases for the JSON schema: valid messages for load testing or erroneous testing to strengthen systems’ error handling capabilities. For testing real-world conditions, it is even possible to automatically generate a realistic mix of valid and invalid messages as they would occur in production use.
Test file generation allows for the broadest possible test case coverage. Easy maintenance of the test data is a significant improvement over any manual processes; this becomes most obvious when API definitions change, as common during the establishment of a new API: whenever an element is for example added or retired or an element type or a business rule changes, all test data can easily be regenerated.
Launching: Onboarding and self-service support, API sandboxes
Once the service is launched, it is crucial to remember that developers expect 24/7 access and online support. Together with XMLdation, and based on the API definition from the implementation phase, banks can provide a self-service portal, comprising of the Validator, Simulator and Wiki services. API sandboxes can be provided, either as a light version, using simple open source interactive documentation (e.g. Swagger UI), or as a more complex sandbox fronting a copy of the production system. The onboarding support tools can be accessed by customers via file upload, web page text entry, or a dedicated API.
It is estimated that up to 80% of API projects are delayed or abandoned during development as APIs are perceived as “buggy” – often the result of insufficient documentation or the lack of feedback on implementation errors. This reveals a human, rather than technical, issue that banks are facing as they start to interact with a new, “millennial”, generation of software developers:
Developers using APIs to build apps are different to developers working on ERP systems. They expect to play around and get things up and running without any communication with the bank: online documentation and 24/7 sandboxes are expected as a given. This sets a new expectation horizon to meet; it has been formulated as the 3:30:3 rule , according to which developers need to be able to:
- understand the purpose of the API in 3 seconds,
- identify its entry point in 30 seconds, and
- create an account, call the system, and use the result in under 3 minutes.
In a typical “trial and error” workflow, the default API error response does not usually explain the source of the problem, but the reason for the failed request. Developers are forced to tinker with their code until it works, often resorting to online forums and peer support channels. While days are passing until a working solution has been found and tested, additional issues start to pile up. Using advanced JSON validation technologies as provided by XMLdation, developers enrolled to self-service API testing receive a diagnostic explanation of the cause and hints to correct the issue, down to a list of faulty line numbers. In most cases, the contextualised feedback and integrated documentation enables developers to fix issues and get the API communication up in an instant.
JSON, the API workhorse
One new technology banks are inevitably facing in the realm of APIs is JSON. Sometimes referred to as “the little brother of XML”, JSON is becoming a ubiquitous format for information exchange. It is the de-facto standard in mobile applications, the internet of things and wherever simple data interfaces are needed. Hence, while PSD2 establishes the overall requirement for banks to provide access to customer accounts and the work on technology specifications is still in progress, JSON, along with XML, is likely to be a technology of choice. It is an accessible format with a low threshold for developers to use.
JSON and APIs are intrinsically tied to each other. While XML accrued its merits as an ideal format for complex documents, critics have always pointed out that it is also a very heavy format. It is best suited for the exchange of multifaceted documents, while the agile and low-overhead JSON format provides an ideal medium for fast exchange of small entities. This is illustrated by the ability of XML to contain large batches of payments at a time, while JSON is usually applied to exchange information on a single payment. Yet, the simplified structure of the file does not make the creation of valid messages less complex. Application logic and business rules still dictate how data has to be structured and formatted. Due to the looser standardisation in contrast to XML, JSON is also more error-prone. For instance, most data is represented as a string while XML uses well-defined formats for date, time, decimals and the like. While it is easy to get started with JSON, there is also more scope for mistakes.
Ultimately, developers’ needs remain as for XML: a message file has to be validated for structural integrity and for compliance with the payment provider’s specifications. Good validation, and good diagnostics on the bank side are essential. XMLdation’s long-standing experience with XML validation, simulation and management is easily extended to this emerging transaction format.
Empowering banks to seize new business opportunities
Along with the ongoing XML revolution in the banking sector, APIs are likely to take on a comparably important—or even more disruptive—role in the years to come. Just as SEPA made ISO 20022 the default in the financial industry, the authority of PSD2 has the potential to establish JSON as a default for mobile banking.
The API offering of the XMLdation SaaS cloud service is built on the same technology as the Validator and Simulator services already used by dozens of banks across Europe: The Validator examines the message and returns a report, including instructions how to fix possible errors and a link to a related Wiki page with further information. Valid messages can be sent to the API Sandbox, simulating the API response based on rules defining its behavior. This keeps development activities independent from production systems (with a range of benefits from performance and administration to security) and even allows users to start developing software before the final API is operational.
XMLdation API services can be made available to public users and partners as well as be used for internal purposes of payment processors. They are a one-stop shop for developers, simultaneously speeding up internal processes and reducing support team workload, providing superior support to existing customers, and attracting external developers to partner with the bank. As the European Commission pushes the market to open up, banks early to the market with well-supported API access are likely to gain a pole position with mobile developers and enterprises.
XMLdation provides the tools necessary to embrace the emerging formats, new style of working, and changes in the banking industry—turning the challenge of “opening up” into a worthwhile investment into new business fields.
With the addition of the API and JSON validation and simulation capabilities, XMLdation’s services make it possible to test XML and JSON files for syntax and compliance with schema and business rules. The service returns diagnostic information in an actionable format for the developer and accelerates app creation by simulating the real API.
 Pekelman, Ori (2012). Lipstick on a pig. How (not) to design a modern API over legacy systems. Presented at APIdays 2012. http://pekelman.com/presentations/apidays/