Public Gaming International Magazine November/December 2016

60 / 84

60 // PUBLIC GAMING INTERNATIONAL // November/December 2016
When setting out on a journey you haven’t made before peo-
ple often check a map before they leave. There is a high prob-
ability that where you’re going, someone has been before and
there’s a well-trodden path. Sometimes that path may be a little
less well defined but there are tracks nonetheless. I believe that
the journey that NASPL is starting to take into the world of
APIs is such a path. Others have been down the same route—
we just need to look for the footprints they left and go a similar
way ourselves.
In this case, the people who have already taken this route are in
the banking industry. Fortuitously there are a great many parallels
to the lottery business, so we can learn a lot from where they went,
and, more importantly, how they got there. The simplest way to
show the parallels between lottery and banking retail systems as
they are today is with a table.
If we’d drawn this table 20 years ago, the banking sector and
lottery would have looked exactly the same. Since then banks have
opened up their systems, securely, and embraced the connectivity
and infrastructure that already exists within the retail environment.
So how did the banks move from a model very similar to the one
deployed by lotteries today, to their current set-up?
Firstly, let’s be clear. We’re not talking about the systems the
banks use in their own offices, we’re talking about the systems used
in retailers for card payments, the systems that are now integrated
to the retailers Electronic Point of Sale (EPoS). And there’s a paral-
lel to the current NASPL API initiative, as initially we’re aiming to
integrate lottery ticket sales into the retailer’s EPoS.
The banks started with a dedicated communication network
connecting dedicated payment terminals to the banks’ systems. The
first step was to connect that payment terminal to the EPoS, but it
was still dedicated hardware, and it still had its own comms. It was
still expensive.
So the banks started using an open network, putting plenty of
security around their transactions, but cutting out the cost of main-
taining a dedicated network. Then the banks agreed on a common
API, which allowed all of the banks to talk to all of the retailers
through the open network, using the same language.
But they still had those expensive dedicated payment terminals
to maintain. Retailers didn’t like it much either because they took
up space, and power. So by using the common API banks allowed
retailers to connect their EPoS systems directly to the banking sys-
tems via the open network.
However, the retailers had to connect their EPoS systems to in-
dividual banks. So a number of third party providers (integrators)
came along who sat in the middle of the retailers and the vari-
ous banks. The retailers just connected to their chosen integrator.
This was one, simple connection. The integrator then managed a
connection to each bank, which was much easier for the retailer,
and much easier for the banks. Of course, if any retailer still want-
ed to connect directly to all of the banks individually they could
do so. The retailer had the choice. The banks listened to what the
retailers wanted.
So, at the end of this process we have banks with considerably
lower running costs, systems which are far less complex, and retail-
Boldly Go where Others Have Been Before …
Simon Butler, Chief Executive Officer, Abacus Solutions