►
From YouTube: Blockchain Governance – Technology is Not the Issue
Description
Financial institutions are sensitive about their data and do not want it available to competitors. The result — they are wary to join any shared blockchain network. We’ve seen this as a sticking point for adoption. MonetaGo convinced competitive finance receivables exchanges to join a Fraud Mitigation Network based on Hyperledger Fabric to eliminate instances of double financing without sharing specific elements of any invoice. MonetaGo CEO Jesse Chenard will walk through achieving the competitors’ buy-in process for this blockchain network now used in production. In this webinar, attendees will learn tricks and tips from direct field experience about how to get buy-in from various (often competing) parties to join a permissioned blockchain network for their mutual benefit while addressing their concerns from a technology standpoint.
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
A
A
First,
this
webinar
is
being
recorded.
So
if
you
need
to
drop
off
at
any
point,
we
will
automatically
send
you
a
link
to
the
recording
via
email
within
a
day
or
two
at
the
bottom
of
your
audience,
console
or
widgets
that
control
all
the
movable
and
resizable
content
windows.
You
can
click
and
drag
the
lower
right
hand
corner
of
each
widget
to
change
the
size
and
you
can
move
the
windows
around
to
customize
the
layout
to
your
preference,
starting
with
the
icon
on
the
left.
A
The
film
reel
controls
the
audio
for
this
event,
or
it
allows
you
to
fast
forward
or
rewind.
If
you're
watching
this
on
demand,
the
Q&A
widget
allows
you
to
submit
questions
to
our
speakers
at
any
time.
During
the
presentation,
we
will
try
our
best
to
answer
as
many
of
them
as
we
can.
If
you're
watching
this
on
demand,
you
can
still
submit
questions
and
we
can
respond
via
email.
The
chart,
icon
controls
the
side
viewing
window.
The
document
widget
contains
links
to
resources.
A
We
think
you
might
find
interesting
as
well
as
a
copy
of
today's
slide
deck.
The
person
icon
opens
a
window
where
you
can
learn
more
about
today's
guest
speakers.
The
clipboard
allows
you
to
access
our
survey
widget,
which
helps
us
collect
valuable
feedback.
Please
take
a
moment
at
the
end
of
the
presentation
to
answer
a
few
questions
about
today's
session
and,
finally,
the
question
mark
opens
a
help
topic
window
in
case
you
experience
issues
with
the
console.
A
If
you're
joining
us
on
an
on
a
bun
to
linux
machine,
please
keep
in
mind,
you
may
experience
legs
and
slide
advancement
and
refreshing.
Your
browser
might
help.
You
can
join
us
on
Twitter
using
the
hashtag,
Elif
webinar
and
don't
forget
to
follow
us
at
hyper
ledger
and
athletics
foundation,
as
I
mentioned,
keep
an
eye
out
from
an
email
from
us
in
the
next
day,
or
so,
with
a
link
to
today's
recording
that
takes
care
of
our
housekeeping
info
I'm
pleased
to
introduce
today's
guest
speakers.
A
Jesse
Shannara
and
Brendon
Taylor
jesse
has
been
focused
on
using
blockchain
technology
to
solve
real-world
problems
since
founding
Manette
ago
in
2014.
Earlier
this
year,
Manette
ago
deployed
its
fraud
mitigation
network
in
India,
based
on
hyper
ledger
fabric.
It
is
one
of
the
first
block
chain
networks
anywhere
in
the
world
to
be
used
for
day-to-day
operations
in
the
financial
services
industry
as
CTO
Brendan,
Taylor
engineers,
Mineta
gos
data
and
blockchain
solutions.
A
B
So,
thank
you.
Everyone
on
the
on
the
call
this
is
Jesse
for
nard
speaking.
Brendon
is
right
beside
me
here,
so
today's
webinar
that
that
the
fine
folks
at
the
Linux
Foundation,
hyper
ledger
have
asked
us
to
discuss,
is
blocking
governance
and
I
think
to
share
some
of
our
experiences
that
that
we've
had,
with
with
the
network
that
we've
taken,
live
and
as
well
as
some
other
similar
ones
that
that
we've
been
looking
at
proposing.
B
So
there's
both
of
us
again.
What
we're
looking
to
fare
here
is
really
some
of
the
tips
and
tricks
that
we
use
to
get
the
the
participants
of
our
initial
network
to
the
table,
but
then
also
I
think
some
of
the
challenges
that
that
we've
encountered,
as
we
talked
about
expanding
the
network,
both
from
a
functionality
standpoint
but
as
well
as
adding
participants
when
we
hadn't
really
planned
for
that
from
from
the
outset.
So
a
little
background
about
Minette
ago,
as
Emily
mentioned,
we
were
founded
in
2014.
B
We
were
headquartered
in
New,
York
City,
most
of
our
research
and
development
happens.
Here
we
come
from
a
very
strong
background,
both
myself
and
startups,
but
then
most
of
the
team
coming
from
a
variety
of
different
sort
of
companies,
mostly
in
the
finance
banking
capital
markets
and
payments
and
settlements,
side
of
things.
In
addition
to
our
New
York
office.
We
also
have
a
subsidiary
in
in
Mumbai.
They
are
responsible
for
sales
and
implementation
and
support.
B
So,
as
a
company
we
went
through
a
slight
evolution
or
in
May
it's
of
startup
speak.
We
went
through
a
couple
different
pivots
in
our
initial
iteration
of
the
company.
We
were
looking
at
how
we
could
leverage
public
blog
chains
and
the
tokens
our
currencies
that
were
available
on
them
to
effect
currency,
conversions
and
money
transfers.
What
we
quickly
learned
was
that,
although
it
was
possible-
and
in
some
cases
you
know,
we
had
people
opt
to
arbitrage
across
different
markets
and
bring
in
a
sort
of
very
low
cost
money
transfers
and
currency
conversions.
B
We
also
realized
that
the
market
that
we
were
trying
to
sell
to,
which
was
financial
institutions,
still
had
a
large
number
of
concerns
and,
in
some
cases,
were
precluded
from
working
with
companies
that
that
handled
crypto
currencies.
Our
tokens
as
we
had
set
that
company
up,
we
had
established
presence
in
bank
accounts
in
a
number
of
different
regions
around
the
world
and
I
think.
B
Luckily,
for
us,
it
was
right
around
the
time
when
hyper
ledger
was
launched
and
and
the
blockchain
buzz
in
the
world
started
to
pick
up
and
went
from
sort
of
Bitcoin
bad
blockchain.
Good
and
one
of
those
areas
that
we
had
set
up
like
I
said,
was
India
and
we
started
to
receive
a
tremendous
amount
of
inbound
interest
from
banks
there.
They,
obviously
a
number
of
concerns
in
that
marketplace.
Bitcoin
had
a
very
big
stigma
attached
to
it
and
it's
being
being
highly
regulated.
B
B
There
is
a
number
of
a
number
of
different
use
cases
that
were
being
put
out
there
and
proposed,
but
we
typically
couldn't
get
them
all
of
the
banks
to
agree
to
what
use
cases
were
first
and
what
have
you
and
then
what
we
started
to
look
at
as
well,
and-
and
this
is
where
we
wound
up
doing
some
work
quite
closely
with
the
Reserve
Bank
of
India,
and
their
research
arm
was
how
to
get
the
regulatory
buy-in.
A
lot
of
the
questions
from
the
banks
were
ok.
B
This
is
technically
possible,
but
where
does
the
Reserve
Bank
stand
on
this
or
where
did
the
various
different
regulators
sit
on
that?
So,
along
with
the
help
from
a
number
of
people
in
the
industry,
we
worked
with
the
reserve
bank
to
come
up
with
a
white
paper
that
looked
at
a
permissible
applications
of
blockchain
technology
and
the
ones
that
the
government
thought
that
you
know
would
be
of
interest
and
things
that
they
could
support
so
that
regulatory
Buy
and
we
found
is
at
least
working
in
the
financial
services
space
extremely
key.
You
know,
typically,
they.
B
The
first
question
is,
after
you
get
past
the
yes,
this
is
a
good
idea.
This
is
something
we'd
like
to
buy
is
well
you
know,
what's
the
legal
opinion
on
this?
Does
it
does
it
sort
of
meet
existing
regulatory
requirements?
Are
there
gonna
be
changes
that
are
required
and
who's
going
to
handle
that?
So
once
we
had
started
to
get
some
clarity
as
to
what
use
cases
the
the
Reserve
Bank
itself
could
support,
then
we
started
trying
to
figure
out
how
to
get
those
use.
B
Cases
live,
and
so
we
started
to
slim
down
on
our
our
our
different
sort
of
central
projects
and
bucket
them
into
ones
where
we
had
broad
support
from
typically
the
market
leaders.
So
those
were
applications
like
trade
finance,
workflows,
information
settlement
to
accompany
existing
payment
rails
to
do
any
number
of
different
things
least
of
which
being
able
to
automatically
update
your
P
systems,
core
banking
systems,
accounting
systems,
obviously
contract
exchange
and-
and-
and
you
know
a
few
others
were
also
naturally
used
cases.
B
As
we
were
going
through
that
process,
we
were
introduced
to
three
receivables
market
places.
So
for
those
of
you
not
familiar
with
invoice
factoring
or
receivables
financing,
it's
where
we
have
a
small
supplier
who
needs
cash
flow
and
and
maybe
has
a
90
day
payable
from
a
large
corporate
buyer.
So
they
take
that
invoice
to
a
financier,
typically
their
bank
or
an
BFC
non-bank
financial
company,
and
they
offer
it
for
sale
to
them
at
a
discount.
B
So
if
I
had
$100
invoice,
the
financier
may
say:
okay
I'll,
give
you
$90
today
and
then
at
maybe
the
due
period.
I
will
collect
the
$100
and
then
keep
my
ten.
So
these
three
receivables
financing
marketplaces
were
in
the
process
of
going
through
the
last
steps
to
go
live
and
they
realize
that
they
had
a
communication
issue
between
them.
B
The
communication
issue
was
that
it
was
completely
permissible
for
a
supplier
to
go
and
offer
their
invoice
across
each
of
these
different
platforms,
but
when
they
were,
when
the
supplier
then
needed
to
or
accept
it
a
bit
on
one
of
their
invoices,
the
other
ones
needed
to
know
not
to
accept
subsequent
subsequent
offers
from
other
finance
ears.
So
classic
sort
of
double
spend
problems
but
more
in
a
real-world
scenarios,
not
not
the
ones
who
are
used
to
in
the
crypto
side
of
things.
So
what
we
propose
them
and
I'll.
B
Let
Brendon
get
into
the
technical
details
of
it
and
some
subsequent
slides
here.
But
what
we
proposed
to
them
was
a
common
network
amongst
them
that
basically
answered
or
address
their
concerns
around
the
privacy
and
the
confidential
nature
of
the
information
and
the
invoices,
but
also
provided
a
subsequently
a
very
actually
kind
of
a
low
cost
mechanism.
B
Even
though,
as
many
people
have
said,
you
know,
couldn't
you
do
this
with
a
central
service
when
they
did
the
cost
analysis
on
a
decentralized
service
with
the
overhead
and
the
auditing
and
what-have-you
as
they
came
out
to
be
much
much
more
expensive
than
than
this
potential
solution
that
we
deployed
for
them.
Interestingly,
in
in
India,
we've
started
now
to
get
the
attention
of
the
rest
of
the
factoring
market,
so
this
is
where
some
of
the
challenges
have
have
come
into
play,
where
initially,
the
three
customers
thought
we
were
building
a
network.
B
You
know
specifically
tailored
for
them,
although
we
do
retain
rights
to
it
and
what-have-you,
but
as
the
industry
started
to
get
word
of
what
we
were
doing
for
the
for
the
these
three
marketplaces,
we
started
to
get
interest
from
some
of
the
largest
factors
in
India
to
join
the
network,
and
so
that,
of
course
presented
a
raft
of
challenges
as
to
how
can
we,
you
know
who
is
allowed
to
join?
What
are
the
economics
or
the
or
the
early
participants
remunerated
in
any
way
for
access
to
what
they
sort
of
think
of
as
their
network?
B
So
those
are,
those
are
a
couple
of
the
things
that
I
think
will
touch
on
as
well.
Now
taking
this
network
to
other
regions
in
the
world,
obviously
we're
a
little
bit
far
prepared
and
I've
got
some
good
experience.
But,
but
you
know
I
think
that's
that's
one
of
the
key
considerations
that
I've
brought
up
actually
a
number
of
times
when,
when
discussing
this,
is
sort
of
establishing
a
good
governance
system
so
that
it's
flexible
for
the
addition
of
different
functionality,
different
participants
and
that
there
are
clear
guidelines
and
rules
for
for
how
that
happens.
B
C
C
Bear
in
mind
that
this
is
all
within
the
context
of
offering
enterprise
great
blockchain
services
for
financial
industries.
Specifically
so
I
know
a
lot
of
listeners
out.
There
may
not
specifically
be
in
financial
services,
and
you
may
not
be
a
blockchain
service
providers.
You
may
actually
be
end-users
of
different
kinds
of,
but
hopefully
some
of
the
learnings
tips
and
tricks
that
we've
got
here,
for
you
might
be
useful.
C
So,
as
Jesse
was
mentioning,
it's
been
kind
of
a
journey
for
the
company
over
the
last
three
and
a
half
years,
making
a
couple
pivots
and
really
trying
to
find
what
the
right
initial
use
case
was
to
deploy
the
technology
and
some
of
the
real
barriers
that
we
initially
faced
were
the
ones
you
can
see
here
on
screen.
So
lack
of
DLT
education.
C
The
next
problem,
along
that
we
had
some
some
real
focus
on,
is
around
privacy,
so
the
three
receivables
exchanges
that
we've
been
working
with.
Obviously
there
is
some
some
real
concerns
that,
if
you're
broadcasting
your
information
now
to
the
rest
of
this
network,
a
lot
of
that
information
can
be
highly
sensitive,
especially
in
the
financial
services
industry.
It
could
be
personally
identifiable
information,
payment,
information,
transactional
contractual,
a
lot
of
different
kinds
of
stuff
could
be
being
passed
back
and
forth
between
the
participants.
C
So
privacy
is
really
concerned
number
one
for
us,
and
that
was
a
large
part
of
our
evolution
away
from
from
public
networks
in
order
to
be
able
to
provide
a
framework
that
ensures
complete
privacy
of
the
information
amongst
the
participants.
Next
is
competitive
concerns,
so
obviously
there
are
various
types
of
networks
that
you
could
implement.
Some
of
them
verticals
such
as
supply
chain
use
case,
which
involves
a
lot
of
different
types
of
participants.
You
know,
could
be
the
inclusion
of
producers,
suppliers
and
buyers,
things
like
banks
themselves
and
shippers
etc.
C
So
so
that
would
be
like
a
vertical
use
case,
but
the
use
case
that
we
have
put
into
place
here
is
very
much
a
horizontal
one,
where
it's
participation
from
a
bunch
of
competitors
who
are
providing
the
same
service
and
it's
obviously
beneficial
for
them
to
share
information
in
some
way.
But
none
of
the
competitors
want
to
give
away
any
kind
of
sensitive
information
about
who
their
customers
are,
what
kind
of
volumes
they're
processing.
So
so
there
was
a
definite
challenge
in
appeasing
those
concerns.
C
Ultimately,
the
participants
need
to
realize
that
the
value
of
the
information
that
they
gain
from
participating
is
much
higher
than
the
potential
loss
of
the
information
that
they
give
away.
Number
four
and
five
here:
defining
ROI
and
cost-benefit
analysis.
They
kind
of
go
hand
in
hand.
So
one
of
the
big
challenges
for
us
was
to
be
able
to
define
the
value
of
this
technology
and
I.
C
So
in
the
case
of
this
network
that
we
put
in
place
the
information
of
the
amount
of
fraud
that
was
happening
across
the
exchanges,
it's
just
not
something
that's
available,
because
the
exchanges
were
not
tracking
it
themselves,
so
so.
Defining
that
the
ultimate
value
of
the
system
is
a
little
bit
sort
of
finger
in
the
air
kind
of
thing.
C
But
as
more
of
these
deployments
happen
over
time
and
we
get
better
data,
then
we
can
start
providing
some
real
analysis
on
on
the
operational
side
of
things
and
doing
that
cost-benefit
analysis.
Analysis
to
ensure
that
that
using
this
type
of
technology
is
actually
the
right
way
of
doing
things
and,
lastly,
lack
of
collaboration.
So
one
of
the
issues
that
we
consistently
came
across
in
trying
to
sell
these
products
is
that
everyone
wants
to
own
the
technology.
C
Everyone
wants
to
use
the
technology
and
leverage
it
as
a
differentiator
and,
as
most
of
you
probably
well
aware,
the
Democratic
nature
of
distributed
ledger
technology
is
kind
of
at
odds
with
that.
It
is
beneficial
to
the
entire
industry
and
it
needs
to
be
sort
of
on
an
even
thing
amongst
everyone
who
participates,
but
using
it
as
a
differentiator
is
kind
of
at
odds
with
that.
C
So
I'm
going
to
talk
a
little
bit
more
about
the
actual
production
solution
that
we've
got
into
place
and
then
the
specifics
of
how
we
overcame
the
barriers
and
this
implementation.
So
as
jessie
was
mentioning,
the
solution
is
around
eliminating
fraud
in
receivables,
financing
so
the
case
being
where
a
supplier
is
able
to
offer
the
same
invoice
for
financing
across
multiple
exchanges
simultaneously.
C
How
does
one
exchange
know
that
one
of
the
other
exchanges
has
actually
already
financed
the
invoice
and
therefore
should
not
process
it
on
their
own
exchange,
so
that
requires
sharing
information
of
what's
being
financed
amongst
each
other
and
again
going
back
to
the
concerns
around
privacy
and
and
competitive
information.
They
don't
really
want
to
share
that
information
that
contains
sensitive
aspects
to
it.
C
So
what
we
do
is
we
create
an
invoice
fingerprint
and
that
is
essentially
just
hashed
information
of
the
invoices,
so
we're
using
the
blockchain
as
an
attestation
to
some
facts
happening
rather
than
using
it
to
store
the
Playtex
information
itself.
And
we
do
we
do
this
in
a
couple
different
ways.
So
it's
not
quite
as
simple
as
just
taking
a
hash
of
the
overall
invoice
fields.
C
So
by
identifying
similar
invoices
that
are
being
financed.
We
are
also
catching
those
cases
where
they
are
visually
sartatia
slee,
trying
to
change
some
of
the
fine
details
on
them,
as
we
mentioned
that
that
preserves
absolute
privacy
across
all
of
the
exchanges
and
ultimately,
as
more
people
join
the
network,
more
banks,
factors
and
discounters
join
the
network
there.
They
can
be
assured
that
all
this
information
that
is
being
broadcast
amongst
the
network
is
is
not
containing
any
sensitive
information
at
all
and
Jesse
mentioned
it's.
It's
pretty
low
costs,
simple
integration.
C
We
try
to
have
Strax
as
much
of
the
blockchain
complexity
to
our
clients
as
possible.
I'll
touch
on
on
this
a
little
bit
more
in
a
minute,
but
one
of
the
other
issues
you
have
is
is
because
the
technology
is
new,
the
actual
end
users
are
not
able
to
implement
it
themselves
and
therefore
they
need
to
have
this
offered
to
them
initially
on
a
kind
of
sass
basis,
so
that
they're
able
to
really
tract
away
that
complexity
and
just
have
simple
end
points
in
which
they
can
they
can
send
and
retrieve
their
information
from.
C
So
how
do
we
actually
get
it
to
implement
this
particular
solution?
As
we
mentioned,
it's
fully
live
in
production,
its
Enterprise
great,
there's,
real
business
information
being
broadcast
across
this
network,
so
so
some
of
the
ways
that
we
actually
were
able
to
implement
this
was
was
by
really
finding
a
smaller
scale.
Business
need
initially
accepted
on
a
lot
of
the
work
that
you
hear
about
being
done
on.
C
As
we
said,
there's
a
limited
number
of
participants
on
this
deployment
we
had
as
the
founding
members
the
three
exchanges.
It's
obviously
a
lot
easier
to
get
three
participants
to
agree
to
the
rules
and
and
the
economics
of
a
network
than
it
would
be
if
you
had
hundreds-
and
we
also
made
it
very
light
way
from
the
cost
perspective.
So
we
use
a
transactional
method
for
charging.
C
So
there's
no
real
upfront
cap
X
to
joining
the
network,
one
of
the
other
problems
that
we
have
in
using
a
technology
that
requires
a
network
effect
is
you
need
to
have
no
barriers
to
entry
for
the
entire
industry
and
there
is
likely
to
be
a
wide
range
of
sizes
and
the
participants
that
join
your
network.
Some
of
them
may
be
processing
just
a
handful
of
transactions
a
year
or
a
month.
Others
may
be
processing
millions
a
day.
C
So
if
there
was
a
heavy
up
from
capex
to
actually
deploy
this
amongst
disappoints,
then
that
unfairness
to
the
smaller
players
would
obviously
present
her
barrier
to
them
participating
and
avoid
the
network
reaching
kind
of
a
critical
mass.
So
having
that
pays,
ego
model
has
been
pretty
beneficial
to
actually
get
these
things
going.
C
So,
on
the
governance
side
of
things,
I'll
talk
about
it
a
little
bit
more
in
a
second
again,
but
for
this
particular
use
case
being
a
horizontal
use
case
where
there's
no
sort
of
real
natural
administrator
or
someone
who
would
provide
that
governance
role,
and
there
is
also
no
value
or
real
sort
of
sensitive
information
being
exchanged
amongst
the
participants.
We
can
afford
to
have
a
more
lightweight
governance
model
initially,
so
our
governance
model
is
administered
by
us
with
Bremen
and
buy-in
by
all
the
participants,
but
it's
essentially
a
code
of
conduct.
C
So
everyone
agrees
to
behave
in
a
certain
way
and
agrees
to
what
the
repercussions
would
be
if
they
break
those
rules
and
that
code
of
conduct
there's
no
real
heavy
legal
framework
required
to
actually
put
that
in
place.
They
don't
need
to
have
an
official
consortium
or
association
or
Federation
in
place
before
actually
being
able
to
join
this
network.
We
can
go
ahead
with
that
light,
a
governance
model
and,
as
I
mentioned
to
begin
with,
we
are
providing
that
that
administration
role
to
the
network.
C
The
longer-term
vision
for
these
networks
is
obviously
to
be
able
to
hand
over
that
that
administrative
role
to
the
network
participants
themselves.
However,
there
is
a
high
level
of
hand-holding
required
at
the
beginning
to
actually
get
them
off
the
ground,
so
so
that
could
be
a
gradual
process
right.
It
doesn't
need
to
be
a
day
one.
This
is
what
you
guys
need
to
do.
It's
it's
super
complicated
and
difficult
and
you're
gonna
have
to
provision
your
own
servers
and
two
upgrades
altogether.
C
So
one
one
of
the
larger
issues
sort
of
more
fundamental
issue:
the
technology
for
the
enterprise
space
that
I
want
to
discuss
quickly
is
around
this.
This
kind
of
dual
personality
of
DLT
there's
been
a
whole
bunch
of
different
versions
and
platforms
of
blockchains
and
D
LTS
about
their.
You
know
the
the
enterprise
focused
one
such
as
hyper
ledger
fabric
and
all
threes
quarter
and
quorum
all
have
a
slightly
different
focus
on
on
how
they
go
about
implementing
this
technology.
But
you
know
it's
it's.
C
C
So,
as
I
mentioned,
you
know
a
lot
of
these
businesses.
Certainly
enterprise
and
banks
have
a
huge
focus
on
privacy
and
maintaining
the
security
around
that
data,
so
that
broadcast
model
really
was
at
odds
with
what
they're
trying
to
do.
But
the
the
great
thing
is
that
we're
now
approaching
a
space
where,
with
the
evolution
in
hypo,
that
your
fabric
and
the
newer
versions,
we
now
have
this
this
concept
of
private
collections.
So
we
can
create
this
hybrid
model
which
provides
the
best
of
both
worlds.
So
we
we
have
that
chain,
whites
storage
of
attestations.
C
So
what
does
all
of
this
mean
for
for
governance?
And
again
this
is
kind
of
from
from
our
perspective
as
a
technology
provider.
Some
of
you
may
have
different
experiences
than
we
have
had,
but
this
is
what
what
our
sort
of
approach
to
this
has
been
and
what
our
user
and
I
know.
This
is
a
particularly
useful
bit
of
information
here,
but
it's
very
much
truth.
C
You
know
the
framework
and
the
complexity
of
the
governance
model
that
you
need
really
is
highly
dependent
on
the
use
case
and
the
service
that's
actually
been
provided
by
the
network.
Our
approach
has
been
to
start
with
use
cases
which
don't
require
that
that
heavy
governance
framework
and
can
have
a
lighter
touch
and
ultimately
progress
on
to
those
heavier
ones
over
time,
as
frameworks
get
put
in
place
and
regulations,
change,
etc.
C
The
primary
concern
of
governance
for
us
should
really
be
around
the
access
control
to
the
network
and
establishing
that
code
of
conduct.
That's
really
it
they're
not
meant
to
be
legal
litigators
in
any
way
whatsoever.
They're
just
meant
to
provide
that
that
framework
for
the
code
of
conduct
and
establish
the
rules
of
who
can
participate,
how
they
can
participate
and
what
happens
if
they
misbehave.
That's
really
it
ultimately,
especially
for
transactional
networks
and
vertical
networks.
There
should
still
be
bilateral
and
multilateral
contracts
in
place
between
the
participants
that
doesn't
come
included
with
with
the
blockchain.
C
So
when
one
bank
is
dealing
with
another
bank,
they
should
still
have
a
master
services
agreement
or
an
is
de
or
whatever
it
might
be
in
place
that
allows
them
to
transact
with
each
other,
and
should
there
be
any
kind
of
need
for
dispute
resolution.
Ultimately,
that
contract
is
what
is
used
to
resolve
that
issue.
It's
not
kind
of
an
automated
legal
framework
where
the
chain
code,
or
whatever
other
type
of
smart
contract,
is
the
ultimate
decider
of
what
happens
in
a
transaction
technology
doesn't
and
can
and
does,
go
wrong
over
time
right.
C
C
With
what
the
wider
industry
goals
should
be
competition
among
solutions
an
obvious
one
again,
there
are
lots
of
platforms
available
out
there
from
from
quarter
and
and
and
fabric,
certainly
for
the
enterprise
side,
but
but
all
the
way
on
the
public
side.
There's
there's
almost
hundreds
of
them
to
choose
from
now.
So
there
is.
There
is
difficulty
in
achieving
consensus
among
these
participants
as
to
what
protocols
should
be
used.
C
So,
coming
to
consensus
as
to
what
the
right
protocol
to
to
implement
for
an
industry
is
critical
and
certainly
a
very
difficult
thing
to
come
to
legal
complexity,
an
obvious
one
and
that's
on
a
few
different
levels,
not
just
from
establishing
governance
for
for
a
complex
use
case,
which
does
require
sort
of
a
heavy
legal
hands
in
establishing
a
federation
or
an
association
whatever
it
might
be.
There's
a
lot
of
legal
complexity
that
could
be
involved
in
doing
those
types
of
things
and
legal
complexity
takes
time
to
resolve
as
simple
as
that.
C
So
trying
to
avoid
that
legal
complexity
is,
is
pretty
critical
to
get
in
your
use
case
off
the
ground
from
day
one
long,
sales
cycles,
at
least
in
the
business
that
we're
in
financial
services.
This
is
this
is
a
disadvantage
to
a
lot
of
startups
and
innovators
out
there.
If
you're
selling
your
product
to
a
small
business,
you
may
get
a
buy-in
on
day
one
and
then
we
start
using
it
the
next
day,
if
you're
going
to
sell
that
same
product
to
a
bank.
C
It's
just
even
if
you
get
buy-in
from
from
the
business
owner
for
the
particular
product
at
the
bank,
it's
going
to
take
them
a
real
long
time
to
assign
those
budgets
and
get
approval
from
all
the
way
up
the
chain
and
do
whatever
orders
they
need
to
do
and
on
board
the
benders
etc.
So
it
just
takes
time
to
get
that
stuff
in
place
and
that's
difficult
if
you're
a
small
phone.
So
so
that's
definitely
been
a
struggle
for
us,
but
now
we're
finally
getting
places.
C
So
so
we
can
appreciate
that
regulatory
reform
we've
been
relatively
lucky
and
well.
We've
actually
architected
a
lot
of
our
solutions
to
be
compliant
with
the
existing
regulations.
But
in
the
case
where
the
existing
regulations
create
a
barrier
to
implement
in
your
solution
that
regulatory
reform
could
take
a
significant
amount
of
time
to
be
put
in
place
in
some
of
the
places
where
we're
operating.
C
We've
been
fortunate
enough
to
actually
have
regulatory
reform
happen
extremely
quickly
where
it's
been
needed
and
we've
participated
in
giving
reasons
as
to
why
that
that
regulatory
reform
is
needed,
but
that's
pretty
rarely
the
case.
It's
normally
going
to
take
an
extremely
long
time
for
regulate
regulator,
to
gather
enough
information
and
data
to
understand
really
how
their
regulations
need
to
evolve
and
change.
So
we
can
expect
that
to
take
a
long
time
and
the
final
point-
enterprise
integration.
This
is
kind
of
on
on
two
levels.
C
The
first
level,
as
I
had
mentioned
before,
is
around
the
knowledge
base
of
the
participants
being
high
enough
to
actually
implement
the
technology
themselves.
The
promise
of
this
technology
is
to
actually
allow
the
participants
to
implement
their
own
interfaces
and
systems
to
participate
in
these
networks.
C
So
every
company
uses
an
ERP
of
some
kinds
and
a
lot
of
these
use
cases,
whether
it's
trade,
finance
or
contract
exchange
or
supply
chain
management,
whatever
it
is
all
of
them,
are
using
their
own
ERP
of
some
flavor
and
it's
very
difficult
to
a
completely
displace
those
systems
in
order
to
replace
them
with
new
interfaces.
So
you
have
to
integrate
these
networks
into
those
existing
applications
because
there's
a
huge
range
of
these
applications
that
also
just
takes
time.
It's
not
an
obvious
thing
to
do.
C
So,
finally,
what's
what's
kind
of
our
advice
from
our
perspective,
so
the
way
that
we've
achieved
our
success
is
to
target
industries
with
a
high
concentration
of
market
leaders
or
even
industry
associations.
So
if
there
is
an
existing
Association
for
your
industry,
dealing
with
that
Association
is
much
better
than
going
bottom-up
from
the
industry
participants
themselves
and
that
can
really
facilitate
it
can
accelerate
it
deployment
and
for
your
used
case
so
and
again
with
that
concentration.
C
If
you
have
to
get
the
buy-in
of
less
than
ten
participants
that
dominate
a
particular
industry
or
market,
that's
going
to
be
a
lot
easier
than
dealing
with
an
industry
that
may
be
spread
across
hundreds
of
participants.
So
so
that
has
been
a
real,
a
real
advantage
to
deploying
our
use
case
so
for
the
specific
business
requirements
over
the
technology.
C
It's
not
technology
that
we're
selling
here
we're
selling
products
that
are
addressing
real
business
needs
and
the
people
that
you
need
to
sell
to
which
I'll
talk
about
in
a
second
here,
how
the
people
that
benefit
from
solving
that
problem.
If
you're
selling
the
technology
in
general
you're
going
to
have
a
real
hard
time
getting
getting
adoption
from
them,
so
it's
it's
a
business
first
approach
from
us
rather
than
technology,
first
keep
complexity,
low
and
gradually
build
on
top
of
success.
So
it
you
know
a
small
wind
is
much
better
than
no
wind
at
all.
C
If
you
start
with
the
small
winds-
and
you
start
building
another
small
wind
on
top
of
that
small
wind
you'll
get
somewhere
in
time.
But
if
you
try
to
tackle
too
much
initially
straight
from
the
get-go
you're
going
to
have
a
real
hard
time
getting
getting
a
buy-in
from
from
everyone
that
you
need
to
architect
for
success
at
all
levels
of
participation.
So
this
is
kind
of
really
more
relevant
to
that
vertical
kind
of
network,
where
you
have
a
lot
of
different
roles
participating
in
a
use
case.
So
something
like
supply
chain
management.
C
You
need
to
incentivize
everyone
that
needs
to
participate
in
order
to
get
them
to
join
the
network.
If
the
network
is
architected
to
provide
a
great
benefit
to
just
one
subset
of
the
rolls-
and
you
expect
everyone
else
to
join
the
network
to
make
that
happen
for
them,
but
there's
no
real
benefit
to
them.
Again,
it's
just
not
going
to
happen
right.
People
are
extremely
busy.
They
have
limited
resources,
limited
budgets.
You
need
to
make
it
interesting
to
every
single
type
of
role.
C
That's
going
to
participate
in
the
network
cell
to
the
employees
in
a
business
who
benefit
most
from
the
solution,
not
to
the
innovation
team.
So
I've
spoken
about
that
a
little
bit,
and
this
is
pretty
critical.
You
know
we
we
are
selling
a
product
that
is,
that
is
solving
a
real
problem
and
a
specific
problem.
So
you
need
to
sell
that
the
people
who
are
going
to
benefit
from
having
that
problem
solved.
C
If
you
end
up
selling
to
an
innovation
team,
they
are
going
to
try
and
leverage
your
technology,
your
solution
as
a
differentiator
for
the
bank
again,
which
is
not
what
you
want
and
and
so
selling
directly
to
those
employees
who
need
the
solution.
Most
is
extremely
important
and,
lastly,
validate
your
ideas
and
approach
across
the
industry.
So
when
you
come
up
with
ideas,
it's
it's
extremely
important
to
socialize
those
ideas
with
the
ultimate
users
of
that
network.
C
B
So
in
that
case,
it's
it's
it's
quite
straightforward,
but
I
think
in
in
more
complex
use
cases
that
we've
seen
and
that
we're
working
on
you
know
it's
it's
it's
being
in
a
specific
industry,
so
whether
you're
a
credit
rating
agency
or
a
depository
or
a
large
corporate
or
a
bank
or
what-have-you
those
those
those
kinds
of
profiles
pretty
much
self-select
and
because
these
are
private
permission,
block
claims
focused
on
somewhat
specific
use
cases.
It's
it's.
B
C
So
the
next
question
I'm
going
to
take
this
one.
How
exactly
do
you
guys
handle
privacy
between
different
orgs?
Creating
a
channel
for
each
set
of
participants?
Participating
orgs
is
obviously
not
scalable,
so
we
have
a
single
channel
for
our
receivables
financing
use
case
the
fraud
mitigation
use
case,
a
single
channel
between
all
participants,
this
being
a
complete
broadcast
model
and
not
containing
any
private
information.
C
A
hyper
ledger
is
obviously
evolving
relatively
quickly
and
the
the
issue
around
using
channels
to
enable
privacy
is
a
little
bit
of
a
complex
one.
But
I
don't
feel
personally
that
it
was
the
right
kind
of
architecture
to
enable
that
and
the
architecture
that
fabric
is
moving
towards
now
is
much
more
capable
and
much
more
appropriate
for
enabling
that
kind
of
privacy,
which
is
with
the
use
of
private
collections
within
a
channel.
C
So
the
private
data
is
held
amongst
the
participants
of
a
transaction
only
and
it's
only
the
hashes
that
have
been
broadcasts
within
a
channel
itself
as
access
station
of
what
actually
happened
in
that
transaction.
So
that's
kind
of
taking
it
back
to
the
core
use
of
these
block
chains
and
using
them
as
as
a
proof,
a
store
of
proofs
and
attestation
of
the
truth,
rather
than
a
store
of
the
actual
information
itself.
C
B
Get
the
next
one
here
considering
me
in
a
vase
that
innovation
teams
would
probably
would
be
probably
involved
in
the
evaluation
of
DLT
solutions.
How
did
you
manage
to
keep
the
feature
set,
unbiased
and
valuable
to
every
participating
organization
and
I?
Think
Brendan
touched
a
little
bit
on
this
one
of
the
things
we've
learned
over
the
last
I'd
say
year
year
and
a
half
is
to
stop
saying
blockchain,
because
when
you
say
blockchain
you
get
shunted
to
the
innovation
team
or
TLT.
B
You
get
assented
to
the
innovation
team,
which
obviously
is
very
excited
and
enthused
about
the
tech,
but
typically
doesn't
have
budget
of
their
own
other
than
a
small
amounts
for
R&D.
So
we
reverse
it
and
we
don't
go
in
and
talk
about
deal
to
your
block,
saying
we
talked
to
the
head
of
trade,
finance
or
supply
management
and
ask
them
if
they'd
like
to
reduce
the
instances
of
fraud
on
their
on
their
invoice
financing
business.
B
Typically,
the
answer
is
always
yes
and
then
so
then,
once
we
dive
into
it
a
little
bit
more
and
explain
the
network
how
it
works,
how
we're
getting
at
the
critical
mass
of
participants
on
at
that
point.
We
then
get
passed
over
to
the
innovation
team
and
it's
kind
of
interesting,
because
at
that
point
then
they've
got
a
business
sponsor
for
the
project.
B
Typically,
the
business
sponsor
will
be
able
to
get
the
budget
for
it
and
when
you
go
in-
and
you
start
talking
to
the
innovation
team-
and
they
discover
that
it's
actually
a
blocks
in
base
solution,
they
get
excited
as
well,
because
most
of
them
have
been
looking
for
a
blockchain
based
project
to
actually
work
on
and
put
into
production.
So
it's
a
little
bit
of
a
little
bit
of
a
different
approach
than
just
like
the
innovation
team
and
saying
hey,
evaluate
our
DLP
solution.
B
C
The
next
question
is
how
many
member
organizations
are
in
the
network.
Does
each
member
run
one
or
more
fabric
pairs,
how
a
decisions
about
membership
services
decided
so
the
first
part
of
that?
How
many
member
organizations?
So
initially
we
had
three.
We
have
now
on
board,
it's
multiple
others,
so
we
are
in
contractual
phases
with
with
various
other
participants
who
will
be
using
the
system
shortly
as
to
does
each
member
run
one
or
more
fabric
peers.
C
Our
current
setup
is
to
actually
run
multiple
peers
per
organization
and
that's
really
for
redundancy
of
their
connection
into
the
network,
so
this
is
obviously
dependent
on
what
your
particular
use
cases
and
how
you
think
it's
best
to
architected.
From
our
perspective,
we
wanted
to
provide
resiliency
in
the
individual
connections
into
the
network,
so
we
have
redundancy
among
the
peers
for
each
organization
how
our
decisions
about
membership
services
decided.
C
So
so
that's
pretty
important
next
question:
how
is
your
solution
really
different
than
traditional
SAS
off
with
a
regular,
centralized
database,
our
participants
of
your
DLT
able
to
use
it
without
you?
So
that's
an
excellent
question
and
one
that's
a
little
bit
tricky
to
answer
so,
as
I
had
touched
on
a
little
bit.
C
One
of
the
major
hurdles
that
we
have
is
getting
participants
who
actually
have
the
skillset
to
implement
their
own
infrastructure,
so
the
SAS
based
offering
that
we
have
is
segregated
by
participant,
so
every
participant
has
their
own
dedicated
environment
and
their
own
dedicated
accounts,
but
it
is
cloud-based
and
we
have
administrative
control
of
those
accounts
to
actually
implement
any
upgrades
and
updates
to
the
system.
The
longer-term
goal
being
to
actually
be
able
to
hand
off
this
administrative
role
to
the
organization
itself.
C
However,
the
reality
is
today,
organizations
are
just
not
ready
to
do
that,
so
it
will
take
some
time
to
get
to
that
point
where
people
are
actually
able
to
realize
the
real
benefit
of
having
this
decentralization
and
distribution
by
taking
ownership
of
their
own
infrastructure.
You
know:
that's
that's
one
of
the
fundamental
difficulties
of
blockchain
and
DLT
is
that
you're
taking
a
service
and
you're
putting
the
onus
of
operating
that
service
on
to
the
user?
You
know
it's
like
telling
users
today
who
use
online
banking.
C
You
know
you
guys
now
need
to
actually
operate
your
own
and
you
need
to
hide
your
own
cash
under
your
pillow
and
do
your
own
finances
you're
not
allowed
to
use
another
service
provider
right
a
lot
of
people
out
there.
Just
don't
have
the
skill
sets
to
do
that,
so
so
it's
it's!
It
will
take
time
to
get
to
the
point
where
people
are
actually
able
to
operate
these
types
of
networks
completely
independently
from
an
administrator.
C
Next
question:
what
happens
when
chains
get
very
large,
especially
for
such
a
large
number
of
transactions
again,
so
this
is
kind
of
an
evolving
topic
with
a
lot
of
these
platforms.
And
how
do
you
deal
with
an
ever-increasing
database
so
so
I
think
everyone
is
perfectly
aware
that
that
needs
to
be
some
kind
of
pruning
mechanism
in
place
to
be
able
to
archive
transactions
and
the
ledger
itself
at
various
points
in
time.
So
so
as
to
what
the
actual
mechanism
that
is
still
being
developed
by
fabric
some
people
may
actually
implement
that
in-house.
C
You
could
potentially
archive
the
whole
thing
and
we
create
a
new
chain
pretty
being
preceded
with
some
of
the
transactional
information
from
the
old
one.
There's
various
ways
that
you
can
do
it
and
I'm
not
saying
that
we
have
the
right
answer
for
that
today,
but
it
is
an
evolving
space.
It's
not
something
that
we
need
to
address
immediately
with
our
particular
use
case,
but
we
do
have
a
solution
for
that
which
will
be
implemented
in
the
coming
months.
So.
B
So
those
markets
that
we
see
Latin,
America,
Southeast,
Asia,
Africa
Mara,
are
are
all
I
think
pretty
pretty
high
on
the
list
and
then
again,
of
course,
you
know
it
goes
back
to
how
do
you
manage
to
get
that
Network
effect
within
each
of
these
markets
and
as
we
get
more
and
more
sort
of
historical
data
on
on
sort
of
the
ROI
and
and
the
number
of
frauds
that
we're
preventing?
You
know,
I
think
that
gets
easier
and
easier,
but
yeah
it's
it's.
C
Next
question
is
I,
know
the
technology,
but
I,
don't
know
the
industry.
So
when
you
say
talk
to
the
industry,
how
do
you
approach
it?
So
I
guess
it's
it's
very
useful
to
have
connections
within
the
industry
to
start
with,
to
start
speaking
to
people,
but,
as
I
said,
your
first
target
should
be
any
industry
associations
that
there
might
be
for
the
particular
industry
so
whether
it's
factoring
or
receivables
financing.
C
B
So
you
know
being
able
to
spell
out
a
clear
business
case
and
and
show
the
efficiency
of
the
network
is
really
how
we
sway
the
decision
makers
and
and
again
we're
typically
talking
to
business
or
product
leads.
You
know,
in
this
case
more
around
trade,
finance
or
supply
chain
management,
not
the
IT
teams.
C
The
next
question:
why
did
you
choose
India
as
your
first
market,
so
part
of
it
was
opportunistic
in
the
sense
that
we
had
established
a
presence
in
India
for
our
initial
business,
around
cross-border
b2b
transactions
using
digital
assets?
So
we
already
had
a
good
good
connections
with
the
banks
in
India.
However,
India
is
a
great
initial
proving
ground
for
this
kind
of
technology
for
a
couple
different
reasons.
C
Firstly,
it's
very
digitally
progressive,
so
they
have
a
lot
of
what
some
people
might
say
a
radical,
but
they
have
to
have
a
lot
of
initiatives
which
are
government
driven
or
otherwise
to
digitize
the
economy
in
a
lot
of
different
ways.
So
you
have
the
ad
hoc
system,
which
is
digital
identity
for
everyone
and
I
know,
there's
some
some
issues
around
using
at
how
now
going
around
the
courts.
But
the
ad
is
not
the
only
example
of
these
types
of
initiatives.
C
So
so
India
is
a
very
digitally
progressive
market
compared
to
others,
not
only
that,
but
having
a
younger
industry
and
in
financial
services
they're
compared
to
say
Europe
or
the
US.
You
have
a
lot
more
ingrained
technology
in
the
in
the
older
markets,
so
it's
it's
much
more
difficult
to
actually
displace
that
technology
and
introduce
new
technology,
whereas
the
Indian
Indian
businesses
are
much
more
willing
to
actually
leapfrog
generations
with
technology
and
implement
the
latest
and
greatest.
C
B
B
If
you
will
but
then
also
in
our
case,
many
of
our
private
investors
come
from
the
finance
industry
themselves,
so
they
either
wanted
they
but
they're
big
believers
and
we're
this
is
going
to
go
or
they
they.
You
know
they
want
to
get
close
to
this
technology
and
learn
more
and
making
investment
was
a
way
to
do
that,
and
then
now,
of
course,
now
that
we've
got
father
market
fit
in
revenue,
it's
the
standard
sort
of
working
with
institutional
investors
to
to
grow
and
scale
it.
B
The
nice
part
is
is
that
we
are
now
in
revenue
generation
mode,
so
there
is
a
pretty
straightforward
path
to
profitability
which
it,
which
is
nice
anecdotally.
One
of
my
former
investors
as
I,
was
talking
to
him
about
what
we
were
doing.
He
said:
well,
why
don't
you
just
raise
an
ICO
and
to
which
I
replied?
Well,
my
customers
pay
me
in
real
money,
so
I,
don't
necessarily
need
to
go.
I
have
an
alternate
current
standard.
C
So
I
think
this
might
be
the
last
question
that
we
have
time
for,
but
if
any
of
you
want
to
continue
the
conversation,
we're
obviously
open
to
chatting
with
many
of
you
over
email,
and
we
can
get
you
details
of
that
just
after
this.
So
the
last
question
you
mentioned
many
times
that
it
took
you
time
to
move
from
one
phase
to
another.
C
Could
you
please
elaborate
on
that
roughly
how
much
time
it
took
you
to
go
through
the
evolution
mentioned
at
the
beginning,
so
so
we
started
the
business
in
2015
when
we
were
doing
that
that
cross-border
business
with
Bitcoin
and
about
six
months
after
that
we
evolved
to
focusing
on
just
DLT
for
enterprise,
but
I.
Think
the
more
important
sort
of
aspects
in
question
in
there
is
is:
how
long
does
it
really
take
to
go
from
idea
to
actual
implementation?
C
And
again
that's
that's,
that's
very
dependent
on
all
the
faxes
that
we
discussed
and
who
you're
selling
to
the
sales
cycle
for
a
bank
could
be
much
longer
than
a
year.
The
sales
cycle
to
a
small,
thin
tech
company
to
onboard
them
could
be
two
days.
So
it
varies
tremendously,
but
in
our
experience
from
actual
idea,
concepts
to
implementation
in
production
has
been
around
the
nine
months
to
twelve
months.