Upload
others
View
19
Download
0
Embed Size (px)
Citation preview
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
May 2016 www.xmldation.com
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.
XMLdation white paper: 3Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
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
May 2016 www.xmldation.com
XMLdation white paper: 4Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
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
May 2016 www.xmldation.com
XMLdation white paper: 5Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
“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
May 2016 www.xmldation.com
Figure 6: Onboarding API developers requires adaptation to the mindset of a new generation of develo-pers.
XMLdation white paper: 6Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
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
May 2016 www.xmldation.com
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.
XMLdation white paper: 7Rapid development tools for API and JSON flows becoming competitive assets to meet PSD2
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/
May 2016 www.xmldation.com