Rapid development tools for API and JSON flows becoming ... · Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2 knowledge of XML banking interfaces,

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 to-

wards engaging with banks' services through a range of mobile, tablet and web apps,

the banking sector is facing on 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 inter-

face between customer-facing applications

and core bank services will remain with the

banks.

Support for any stage of API roll-out

Rolling out an API programme consists

of four major phases for a bank:

1. Exploration of business and technical

options,

2. Implementation, by defining APIs, buil-

ding their end points and connecting to

the bank's systems,

3. Testing of the APIs, and

4. 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 re-

placement version behaving similar to the

real API, including validation and simulated

May 2016 www.xmldation.com

White paper

API

XMLdation white paper: 2Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2

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


Figure 1: The provision of API platforms is an extension of banks' service portfolio, enabling new business opportunities with internal and external customer service interfaces.

Figure 2: The four stages of banks' API programmes, and how they are supported by XMLdation's service offering.


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.

Figure 3: The XMLdation cloud services simulates the behaviour of banks' APIs - even before they have been established. The sandbox user receives actionable error reports or a simulated response message.

Rapid API prototyping helps business

and other stakeholders establish a more

concrete understanding of the APIs and

their potential. It enables the early vali-

dation 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, expres-

sing 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 explora-

tion phase can easily be updated to reflect

the agreed API definition.

Figure 4: With API descriptions and business rules stored in the message management system, implementation guides can be created in an instant and are always up-to-date.

If desired, a SaaS collaboration environ-

ment 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 redu-

ces risks, as the API is well defined and un-

derstood by all stakeholders. This way, the

API will be aligned with banking API stan-

dards 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 respon-

ses and can be used in the cloud or by de-

ploying 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 frame-

works 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 gene-

rated 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 realis-

tic mix of valid and invalid messages as

they would occur in production use.

Figure 5: Test files can be auto-generated based on a real-world mix of valid and erroneous JSON messages.

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 [1], 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 ex-

change. It is the de-facto standard in mo-

bile 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


Figure 6: Onboarding API developers requires adaptation to the mindset of a new generation of develo-pers.


be a technology of choice. It is an accessi-

ble format with a low threshold for develo-

pers 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 docu-

ments, 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 in-

stance, 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 valida-

tion, 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


Figure 7: Using XMLdation myXML for API message management yields a broad range of benefits for both the API provider and for developers using the API.


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 res-

ponse based on rules defining its behavior.

This keeps development activities indepen-

dent 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 wor-

king, and changes in the banking industry—turning the challenge of “opening up” into a

worthwhile investment into new business fields.

[1] 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/


Documents

Rapid development tools for API and JSON flows becoming ... · Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2 knowledge of XML banking interfaces,