►
From YouTube: Future Finance Data Innovations with Open Banking and PSD2 Eero Arvonen (Suomen Asiakastieto)
Description
Future Finance Data Innovations with Open Banking and PSD2
Speaker: Eero Arvonen (Suomen Asiakastieto)
The OpenShift Commons Gathering was held on Jan 29th, 2020 in London, UK, and featured guest speakers from local customers and users. The OpenShift Commons Gatherings brought together 300+ experts from all over the world to discuss container technologies, best practices for cloud native application developers and the open source software projects that underpin the OpenShift/Kubernetes ecosystem.
https://commons.openshift.org/gatherings/London_2020.html
A
Okay,
hi
everybody
I
was
going
to
start
off
by
thanking
Diane
for
holding
this
great
event,
but
since
we're
you
have
scheduled
I'm
gonna
skip
that
part.
If
that's
okay
with
you
all
right
so
quick
introduction,
my
name
is
Sarah
Vernon
I'm,
currently
working
for
Sherman
Osaka
stay
atop
I've
been
with
us
ever
since
early
2016.
A
My
background
is
in
Java
development.
Currently
I
spent
my
time
about
5050
between
doing
you
know,
project
soft
software
projects
and
doing
other
cool
stuff
like
improving
our
CI
CD
pipeline
or
trying
out
new
technology,
so
I'm
presenting
sominus
aircraft
at
the
which
is
part
of
Aussie
except
the
group.
Alongside
a
company
called
you
see,
we
are
listed
on
the
Helsinki
Stock
Exchange.
A
A
We
are
also
a
clean
tech
company
and
we
help
our
finance
clients
enhance
their
business
opportunities
by
bringing
new
data
innovations
to
the
market
and
our
largest
customer
segment
is
segments,
rather
our
banking
and
finance
insurance,
and
in
brief,
our
products.
Our
services
are
primarily
used
for
stuff,
like
risk
management,
finance
administration,
business
in
making
sales
marketing
that
type
of
thing,
and
our
goal
is
to
deliver
automated
and
accurate
services
for
these
functions.
Now.
A
Why
should
you
listen
to
instead
of
reading
emails
and
Twitter
for
the
next
30
minutes?
Here's
why
I'm
gonna
tell
you
why
a
company
like
us
is
interested
in,
or
rather
decided
to
jump
into
the
open
banking
space.
I'm
gonna
tell
you
about
the
product
that
we've
already
built
and
launched.
I'm
gonna
demonstrate
you
what
it
does
and
I'm
gonna
talk
to
you
about
the
design
choices
that
we
put
into
it.
A
I'm
also
gonna,
take
a
look
into
the
future
and
speculate
on
what
kind
of
products
we're
gonna
see
going
forward
and
finally,
I'll
show
you
how
I
took
our
open
banking
product
account
inside
to
the
next
level
by
migrating
it
on
to
Quercus,
which
is
a
framework
for
cloud
native
java
and
here's
some
pretty
picture
our
marketing
department
conjured
up.
So
after
the
financial
crisis,
we've
had
plenty
of
brand-new
regulation
in
the
financial
sector.
A
This
new
regulation
brings
new
business
in
in
two
distinct
ways.
First,
off
banks
have
more
need
for
our
existing
risk
management
services,
because
regulation
demands
it
now,
and
secondly-
and
this
is
the
case
with
with
the
PSC
and
the
accounting
side-
is
that
we
are
getting
access
to
new
data
sets
which
we
can
leverage
to
build
better
products
on
new
products.
A
Now
financial
institutions
are
getting
the
short
end
of
the
stick
in
that
this
will
drive
up
their
costs
and
this
might
disrupt
their
business
models.
So
what
fintax
like
us
need
to
offer
is
automated
solutions
based
on
these
new
data
sets
via
scalable
technology,
and
since
we
are
competing
in
a
highly
regulated
market.
Complying
with
the
regulation
is
key.
A
So
it
all
kind
of
started
several
years
ago
by
us
investigating
what
changes
PST
to
will
bring
and
how
it'll
affect
our
clients
and
our
business
with
them.
So
after
that,
after
studying
it
for
a
couple
of
years,
our
clients
actually
started
asking
us
for
solutions
and
like
what
what
they
should
build
on
on
top
of
this
new
regulation
and
whether
we
can
present
them
with
business
opportunities.
And
now
we
are
at
the
stage
where
our
version
1.0
has
been
launched
and
first
customers
are
live
and
we
are
starting
to
build
even
more
stuff.
A
So
then
a
few
words
about
the
service
we've
built
account
inside
yeah
we're
now
we're
getting
to
the
part
which
I'm
qualified
to
actually
speak
on.
I
would
say
any
product
that
aims
to
be
a
great
product
has
to
have
some
sort
of
a
impact
in
society,
and
we
did
try
and
build
a
product
that
is
really
great.
So,
let's
have
a
one
was
like
recap
of
what
it
is
that
we
do.
Our
CEO
had
fights
against.
Over-Indebtedness
is
in
Nordics
as
a
short
summary.
So
this
is
what
our
service
does.
A
Ok,
this
was
supposed
to
come
one
by
one,
but
basically
we
access
bank
accounts
of
a
loan
up.
The
bank
accounts
of
a
loan
applicant
has
worth
known
as
pay
PSU
or
payment
service
user
based
on
their
consent.
Yeah,
we
process
the
bank
account
data
in
the
context
that
they've
chosen
on
behalf
of
the
creditor.
That
is
the
where
there,
where
they
are.
You
know
applying
for
loan
that
we
deliver
actionable
facts
regarding
the
applicants,
financial
behavior
from
this
data,
and
we
all
do
all
this
in
a
compliant
way.
A
So
how
does
bank
transaction
data
create
value?
How
do
you
create
value
of
bank
transactions?
First
off,
we
are
currently
able
to
calculate
ability
to
pay
and
cash
flow
out
of
people's
bank
account
data.
That's
how
much
money
you
bring
in
versus
how
much
money
you
spend
and
also
how
much
money
you
have
on
your
account
at
different
times.
A
A
We
decided
to
run
this
application
as
containers
and
open
ships.
We
have
a
private
opposite
cluster
and
yeah,
that's
of
where
it
could
go
that
way
and
based
on
that,
it's
quite
natural
to
go
with
a
micro
service
architecture
right.
We
chose
thorne
tail,
also
known
as
while
flights
warm
for
the
back
end.
A
We've
been
running
EAP
at
Ostia,
Castillo
/a
for
several
years
now,
and
we
kind
of
saw
thorn
tail
as
a
natural
evolution
for
for
like
monolith,
EAP
type
of
stuff,
we
picked
react
and
nodejs
for
our
front
end
we're
able
to
go
with
the
latest
Java.
So
why
not
write
Java
11
this
and
then
our
product
owner
asked
for
us
to
build
something.
A
She
called
joints
into
this
service
and
what
I
mean
by
that
is
the
PSC
to
space
is
very
in
terms
of
standards,
it's
very
unregulated,
so
each
and
every
bank
will
have
their
own
API
through
which
you
download,
stuff
stuff
will
be
named
differently.
Different
authentication
mechanisms,
all
that.
So
we
have
to
be
able
to
change
this
stuff
on
the
fly
and
we
also
need
to
be
able
to
have
partners
that
aggregate
a
set
of
bank
api's
in
order
to
harmonize
them
and
make
it
easy
for
us.
A
So
we
don't
have
to
do
that
job
of
integrating
to
every
single
bank.
There
is
out
there
and
then
other
parts
of
the
process
should
also
be
detachable.
For
instance,
what
if
we
had
a
service
that
just
wanted
to
download
the
bank
account
data,
but
not
utilize,
the
calculation
that
we
do,
that
has
to
be
touchable
part
of
the
process
or
how
about
what?
If
some,
some
of
our
customers
already
have
the
bank
account
data
so
that
they
don't
need
that
part.
A
They
just
need
to
call
the
service,
the
calculation
part
with
the
account
data
that
they
already
have.
So
that
also
has
to
be
a
thing
that
can
be
separated
now,
there's
obviously
some
interplay
between
all
these
bullets
right,
so
containers,
micro
service
architecture
and
then
the
four
entail
thing
where
you
are
actually
able
to
build
the
Builder
stuff,
so
I
think
our
serve
design
philosophy
got
quite
well
aligned
with,
with
this
set
of
technologies,.
A
A
This
is
the
application
architecture
of
account
insight.
We
have
a
grand
total
of
eight
micro
services
and
a
database
and
a
cache
and
the
production
runs
on
just
about
20
containers
and
let's
go
through
the
different
parties
at
this
time
as
well.
So
there's
our
customer,
the
creditor-
that's
gonna,
be
on
here
at
the
top
left,
the
bank
logo
under
them,
there's
the
end
user,
the
PSU
payment
service
user
and
then
on.
A
So,
let's
go
through
a
little
bit
of
what
the
what
each
micro
service
does
so
there's
one
set
of
micro
services,
that's
responsible
for
the
process
flow,
there's
the
the
top
one
called
the
interface
to
PS
interface.
Psd
to
rest,
that's
the
process
flow
from
the
perspective
of
the
Oracle
int
Bank,
then
there's
the
PSD
to
client,
which
controls
the
process
flow
from
the
perspective
of
our
of
the
end-user
and
then
there's
the
PSD
to
Orchestrator,
which
controls
the
process
from
the
perspective
of
a
seer
Costello.
A
Now,
if
we
wanted
to
change
the
flow,
somehow
you
could,
you
can
see
how
this
is
pretty
well
detached.
Now
we
could,
if
we
wanted
to
alter
it
in
any
way
we
just
have
to
edit
one
or
two
or
three
of
these
services
and
not
the
rest
of
them,
so
pretty
basic
micro-service
stuff,
but
still
it's
a
pedestrian.
It
works.
A
A
Now,
if
you
ever
go
into
your
banks
like
online
through
a
browser
to
your
bank
online
bank
and
look
at
your
account,
you're
gonna
see
a
bunch
of
transactions
and
if
you
look
at
the
counterparty
of
transactions,
I
don't
know
what
the
case
is
for
you
guys,
but
when
I
go
there,
some
of
the
names
have
nothing
to
do
with
the
actual
company
that
I've
been.
For
example,
if
I
go
to
the
gas
station,
it
might
say
something
like
zero.
Four
two,
two
zero
Helsinki
and
not
like
gas
station
X.
A
A
A
A
I'm
gonna
be
accessing
a
sandbox,
that's
built
on
top
of
a
sandbox,
that's
built
on
top
of
another
sandbox
through
VPN
via
you
know,
mobile
Internet,
so
just
in
case
something
goes
wrong.
Let's
all
agree
to
blame
somebody
else.
It's
not
my
fault,
so
here
we
have
a
or
testing
tool.
This
is
kind
of
mocking
the
the
creditor
in
the
process.
So
you
can
see
whoops
here
you
can
see
the
initial
message
that
our
our
customer
would
sent
and
we're
actually
gonna
edit
this
one
right
now
to
make
the
process
slightly
more
simple.
So.
A
They're
gonna
call
one
of
our
endpoints
they're
gonna
get
some
stuff
as
a
response
and
then
they're
gonna
forward
the
loan
applicant
to
our
service,
and
this
is
what
the
app
loan
applicant
would
see
on
our
service.
Now
this
is
finished
I'm.
Sorry,
we
don't
have
an
English
version
for
this
I.
Don't
know
why
you
can
ask
the
product
owner
or
something
this
is
for
accepting
the
terms
and
conditions,
and
nobody
ever
reads
those,
because
this
is
just
like
that
bank
data,
it's
nothing
important
and
then
there's
Bank
selection,
so
we're
gonna
go
with
well.
A
A
Wonder
if
I
still
remember
this-
and
this
would
be
two-faced
so
now
my
phone
would
ring
and
then
I'd
get
a
code
and
I'd
input
it
here
and
mind
you
these.
These
a
couple
of
last
degrees
are
the
bank's
screen.
So
we
have
no
control
over
our
seekers
that
has
no
control
over
what
they
see
there,
but
basically
they're
doing
the
customer
authentication
and
then
they're
gonna
get
a
list
of
their
bank
accounts
here,
so
we're
gonna
choose
these
two
accounts,
be
here
are
the
balances.
A
This
is
not
my
account
disease
test,
so
we're
gonna,
say
I'll,
see
if
I
can
access
these
two
accounts
and
we're
gonna
click
accept,
and
then
it's
going
to
redirect
us
back
to
account
insight
built
by
us
and
we're
gonna
be
able
to
download
the
data
it's
gonna
take
a
while.
So
we
can
just
take
the
time
by
admiring
this
guy's
beard.
Okay,
we're
ready
already
it's
faster
than
usual.
A
Here
we
can
review
the
actual
raw
data
if
we
want
to
so
the
end
user,
again
reviewed
the
data
if
they
wish.
So
this
is
just
JSON
right,
but
here
are
all
the
transactions
they've
had
for
the
last
12
months
or
something
so
they
can
review
their
own
data.
This
is
a
gdpr
thing,
I
think
so,
but
the
process
doesn't
terminate
here
for
the
for
our
customer,
the
creditor
right,
because
they're
gonna
want
to
get
the
calculated
results
as
well.
A
So
we're
gonna
take
a
look
at
the
testing
tool
and
say
get
latest
rural
engine
results
boom.
Yes,
it
worked
and
we're
gonna.
There
are
plenty
of
rules
here,
like
I.
Could
scroll
down
there's
plenty
of
stuff
here,
but
I'm
gonna
do
one
that
I
know
here:
largest
positive
transactions,
name
t-mobile,
doll,
okay,
this
is
finish,
and
it's
also
misspelled,
but
basically
what
our
service
is
telling
us
is:
there's
there's
someone
called
t-mobile.
Evolute
limited
company
who's
been
sending
us
money
over
the
last
six
months
on
average
once
per
month.
A
Well,
this
is
the
previous
30
days.
This
is
in
30
days
before
that
and
etc.
For
the
last
last
six
months-
and
it's
telling
us-
it's
been
a
total
of
15,000
over
the
last
six
months
and
an
over
a
total
of
30,000
over
the
last
12
months.
So
now,
if
this
guy
had
applied
for
credit
and
said
they
work
for
people,
Palo
Alto
and
their
salary
is
something
like
net
seller
is
something
like
what
is
that
two
hundred
twenty-five
hundred
per
month
we'd
be
inclined
to
believe
them
right?
A
A
We
can
go
from
code
to
our
test
environment,
then
even
into
production
in
less
than
five
minutes.
That's
pretty
good!
You
never
want
to
do
that.
Though.
Containers
and
micro
services
lead
to
freedom
of
choice
in
technology.
We
could
do
thorn
tail,
for
which
I
don't
think
we
had
a
proper
runtime
environment.
Without
open
ships,
we
could
do
Java
11.
A
We
have
high
availability
to
scale
and
automate
a
recovery.
This
leads
to
you,
know
better
up
times
and
and
whatnot,
and
just
to
summarize
so
these
also
each
one
of
these
also
has
two
concrete
business
benefit.
So
quick
setup,
like
I,
said
it
saves
time
and
time
is
time.
Is
money
right,
lower
battery
to
decouple
stuff
leads
to
higher
quality,
hopefully
quick
to
deploy,
means
faster,
lead
time.
A
So
a
bit
of
speculation
on
what's
gonna
happen
next
with
with
the
open
banking
stuff.
With
regard
to
how
how
we
see
it.
Basically,
these
are
the
things
we're
talking
about
building
next
now
the
thing
I
showed
you
was
about
a
loan
applicant,
getting
their
their
credit
rating
by
some
automated
means
right
now.
What
if
we
thought
this
the
other
way
around.
Currently
we're
not
is
not
saving
the
data
in
any
way
we
get
it.
We
process
it,
we
send
it
to
the
creditor,
and
then
we
discard
it.
A
A
So
we
can't
single
anybody
out
and
then,
with
sufficient
data,
we
can
draw
conclusions
like
women
aged
twenty
to
thirty,
four
prefer
aging
and
desire
in
stockholm.
Seventy
seven
percent
to
twenty
three
percent
right.
So
we
can
do
all
these
cross-cutting
things
with
this
big
data
that
we
have.
We
could
also
say
stuff
like
okay,
but
desire
has
been
gaining
market
share
at
a
rate
of
point
three
percent
since
2015.
A
A
We
are
seeing
and
we're
again
gonna
change
places
here,
because
it's
time
to
go
sub-atomic,
let's
have
a
show
of
hands
here.
Who's
heard
of
Quercus
and
who's
tried,
Quercus
and
who's
working
on
an
actual
project.
That's
gonna
be
in
production,
the
Quercus,
okay
and
who's
who's
already
in
production
with
Farkas.
Okay,
just
me,
then
so
remember
this
light
from
earlier
this
one,
it
hasn't
been
accurate
for
quite
a
while
anymore.
A
A
A
The
native
executable
part,
which
I've
done
the
migration
of
is,
is
not
painless.
It's
actually
well
you'll
see.
So
these
are
the
pain
points.
Basically
reflection.
If
you
use
reflection
in
Java,
you're
gonna
run
into
some
issues.
I
did
it
kind
of
trial
and
error,
so
it
took
me
quite
a
while
to
really
get
that
down.
There's
pretty
basic
stuff
like
your
SSL.
So
if
you
want
your
HTTP
clients
to
do,
HTTP
calls
you're
gonna
have
to
do
some
extra
stuff.
A
Now
there
are
guides
for
this
on
on
the
quark
instead
io,
but
due
to
our
special
circumstances,
we
had
to
do
some
extra
stuff
with
that,
and
that
was
not
cool
also
if
you're
using
web
service.
So
that's
jax-ws,
that's
I
do
I,
couldn't
get
it
to
work
and
as
far
as
I
know
it
doesn't
work
on
the
native
mode,
so
I
had
to
go
and
change
some
stuff
within
our
legacy.
Applications
to
expose
toughest,
REST
API
so
instead
of
web
service
API.
A
Then
there's
the
fact
that
the
application
is
is
booted
at
Build
time
instead
of
you
know
startup,
so
you
boot
the
application
during
the
native
compilation,
and
that
runs
into
some
issues.
If
you're
not
careful
at
Osseo
says
oh,
this
is
how
our
configuration
management
works
during
startup,
we
download
environment
specific
stuff
over
HTTP.
A
Now,
that's
not
going
to
work.
If
you
do
that
build
time,
because
you're
gonna
do
your
build
so
that
you
can
run
it
anywhere
right,
so
ya
had
to
have
to
fix
some
stuff,
but
the
migrated
workers
is
good
for
highlighting
the
stuff
doing
wrong.
So
I
would
definitely
recommend
that
and
then
there's
login
configuration
the
way
we
configured.
Our
logging
wasn't
compatible
with
this,
so
we
had
to
do
some
stuff
to
get
around
it.
A
If
you
guys
want
to
chat
about
these
pain
points,
I
have
they
seem
in
much
more
detail
and
you
can
see
much
more
painful
expressions
on
my
face.
Trying
to
you
know,
discuss
this
so
just
come
up
to
me
later
and
we
can
have
a
chat
so
enough
with
the
with
the
pain.
Let's,
let's
see
the
games
right.
So
we
are
being
promised
smaller
footprints
and
I.
A
Did
some
performance
tests
on
this
and
I'm
gonna
show
you
the
results
in
two
sites,
so
there's
the
resource
utilization
part
that
interests
us
and
the
other
is
performance
right,
so
resource
utilization
first,
so
here
we
have
three
deployments.
The
left,
one
is
the
application,
as
it
is,
the
middle
one
is
quark,
isn't
JVM
and
that
one
on
the
right
is
corpus
on
the
native
compiled
version.
A
A
We
cut
that
down
by,
like
I,
don't
know
75
percent
or
something
and
with
the
native
deployment,
where
the
deployment
was
restricted
to
50
megabytes
of
ram.
The
consumption
was
down
to
41.
So
that's
like
20
to
1.
That's
that's
pretty
good
and
then
the
final
column
is
the
CPU.
So
out
of
the
box,
we
had
a
CPU
utilization
of
350
million
cores.
Now
this
is
just
reference
numbers
basically
and
with
a
JVM
it
went
down
to
1/2
157
s
about
60%,
I,
suppose
and
then
going
to
the
native
one.
A
A
Ok,
people
are
falling
asleep.
So
it's
let's
move
forward
so
performance.
The
first
elephant
in
the
slide
is
the
60%
bar
there.
Isn't
it
so
thorn
tail
used
to
take
1
minute
to
boot,
up
and
migrating
to
quark
is
JVM.
We
took
that
down
by
90%
and
going
to
the
native
another
90
percent,
or
so
so.
Currently,
the
application
is
starting
in
about
0.4
seconds.
Now
it's
not
good
enough
for
serverless.
A
But
the
reason
is
our
configuration
management,
like
I,
said
it
downloads
stuff
over
HTTP
during
startup,
so
it's
not
gonna
be
like
10,
milliseconds
or
whatever,
and
then
there's
through
a
boot
I
was
actually
surprised
to
see
that
the
true
boot
went
up
quite
significantly.
The
throughput
was
3.3
calls
per
second
for
for
thorn
tail
and
I'm,
talking
sequential
call,
so
you
make
one
call
and
when
it
returns
you
make
the
next
one.
A
A
I
think
there's
something
missing
here:
okay,
so
the
pain
is
real
with
legacy
applications,
so
I
wouldn't
recommend
everyone
to
go
and
migrate.
All
of
your
you
know:
legacy
apps
onto
quark
is
native
right
away
because
you're
gonna
be
in
a
world
of
pain.
That
way,
maybe
use
it
on
some
fairly
modern
thing:
you
you
know
build
last
year
or
do
it
on
current
greenfield
projects,
but
the
JVM
Quercus
thing
is
definitely
for
everybody
and
I
would
suggest
trying
it
out
there
stuff
I
didn't
mention
like
the
testing
framework
and
a
development
mode.
B
Everybody
can
smell
that
lunch
being
piped
in
here.
So
thank
you
very
much
and
it's
wonderful
to
see
Quercus
being
advocated
for-
and
this
is
also
I
think
just
I
wanted
to
say
when
we
asked
people
to
give
us
their
case
studies
and
their
stories,
we're
not
asking
for
the
the
cleaned
up
version.
We
like
to
hear
your
pain
points
and
get
the
feedback.
That's
really
one
of
the
wonderful
things
about
having
a
community
event
we're
not
trying
to
sell
you
anything
we're
trying
to
share
the
stories
and
the
war
stories.