1.
Clouds and chains
Opportunities and Challenges for Financial
Services in the cloud (...but mostly challenges)

2.
Disclaimer
● These slides contain names of specific
companies. This is for illustrative purposes only
and is not intended to be seen as an
endorsement.
● The contents herein does not reflect the views
or opinions of anyone else but myself.
● I am not a lawyer.

3.
Who in the audience...
● Is a lawyer?
● Data privacy expert?
● Runs their own node and/or a node on behalf of
someone else?
● Is building some type of cross-border
technology-based infrastructure? (… like a
blockchain)

4.
In less than 280 characters

5.
And just on Sunday
“Some blockchains, as currently designed, are
incompatible with the GDPR. EU regulators will
need to decide whether the technology must be
barred from the region or reconfigure the new
rules to permit an uneasy coexistence.”
- Michele Finck, Oxford University

6.
General Data Protection Regulation
● If a company processes data of EU citizens or
targets them, data protection regulations in the
EU have a big impact on how a company can
operate in Europe
● In the case of GDPR, it doesn't matter if the
entity is a small or big organization, or a
financial company because there is no
distinction based on an industry
− Note: Germany was the 13th largest trading partner
(measured in imports) for South Korea in 2017

7.
Other 'Older' quotes
● Brock Pierce in May 2016: “The solution to
SWIFT's issues is blockchain”
− Verdict: No, SWIFT’s security issues at the time
were not directly solvable because of the usage or
adoption of a blockchain.
● E&Y July 2016 report: “Blockchains may also
cause the ground to shift rapidly beneath
providers of cloud services, especially
infrastructure-as-a-service (IaaS) providers.”
− Verdict: TBD, depends on what a “blockchain”
actually is viewed as in practice.

8.
Everything onto a blockchain?
● Even if it was technically possible to somehow
store and secure all financial information on a
blockchain (which it probably isn’t), each
country has its own specific laws surrounding
‘regulated data’
● And encryption probably isn't the silver bullet
answer, more on this later.

9.
Pre-GDPR that are on the books
● “Right to be forgotten”: existed in EU and
Argentina and other regions for ~10+ years
● Personally Identifiable Information (PII):
− HIPAA; Financial Privacy Rule / Safeguards Rule;
FISMA; Fair Credit Reporting Act; Regulation S-P;
Data Protection Act of 1998
● BCBS 239: core principles for effective Risk
Data Aggregation and Risk Reporting (RDARR)
practices
− Sidenote: data lakes

10.
What laws are data subject to?
● Subject to the laws of the country in which the
company (subsidiary) is located?
● ... in which it originated?
● … in which the cloud provider is
headquartered?

11.
IO.com
“In the cloud, data sovereignty can become an issue
because different countries have different laws
governing the collection, use, storage, and
transmission of data within their borders. So data
sovereignty really is the question of which sovereign’s
(i.e., country’s) laws govern your data.
A related issue is that of data custody, which is about
who controls your data. Essentially, who has the right
– or the obligation – to hand it over if the government
comes knocking?”

12.
“As many details of the GDPR are still subject of
interpretation and companies discussing it will have
a competitive advantage in the EU if they are able
to adapt their technological infrastructure and
business models in accordance with the
requirements under the GDPR.
A forward-looking privacy by design approach
will be key.”
- Jana Moser, attorney and founder of Data Reality

13.
US and the EU
● In 2015, the EU Court of Justice decided that
Safe Harbor isn't valid anymore.
● As a result, Privacy Shield is being negotiated:
to make companies that abide by the framework
agreement are deemed to have an equivalent
data protection level.
● On-going case centered around a Microsoft
data center in Ireland which essentially says
that these privacy model clauses are not valid.

14.
Solutions?
● How to handle and solve for the problem
surrounding sensitive information that cannot
leave the border?
● Even if you encrypt sensitive data, if it is stored
by a third party it still creates potential
vulnerabilities:
− Even with state-of-the-art encryption tools, allowing
third parties to hold the data creates potential future
risks
− Some of this risk can be controlled via strict
certification process and contractual/legal recourse

15.
“But muh encryption!”
● Trade-off: you can try to be your own bank
(e.g., a “sovereign” cryptocurrency user) but in
practice due to convenience, a large portion of
private key holding is outsourced to institutions
such as banks and trusted intermediaries
● Now the third party has time to “crack the lock”
so to speak and/or be subpoenaed
- Also UX tradeoff

16.
Opportunities

17.
Be your own cloud! Or maybe not

18.
Sovereign clouds
● Sovereign clouds for data sovereignty is a
proposed solution.
● Microsoft Cloud Germany is a sovereign cloud
operated by a German data trustee.
● Microsoft Azure Government cloud is a cloud
for just the US government.
− “Information Impact Level 5 DoD Authorization”

19.
AWS Secret Region
● The AWS Secret Region can operate workloads
within several U.S. security classification levels.
● “With the launch of this new Secret Region,
AWS becomes the first and only commercial
cloud provider to offer regions to serve
government workloads across the full range of
data classifications, including Unclassified,
Sensitive, Secret, and Top Secret.”

20.
Private clouds
● April 2, 2015: BNY Mellon launched a private
cloud platform called NEXEN:
“Allows programmers to build and store banking
and trading apps. The platform, built largely with
open source code, also includes a catalog for
storing application programming interfaces,
essentially instructions that tell software
components what to do.”
● Private cloud providers for banks: Oracle,
Cisco, IBM, BankOnIt

21.
What do sovereign clouds and
“secret spaces” have to do with the
DLT-related industry?

22.
Anarchic versus archic
● In practice, most blockchain implementations
are effectively cryptographically linked data
structures housed in a cloud
● Anarchic / public blockchains such as Bitcoin
and Ethereum typically use a decentralized
“cloud” comprised of non-KYC'ed
pseudonymous validators (nodes)
● Private / permissioned chains sometimes use a
“cloud” in which all validation is handled by
known, legally accountable parties and all
identities are KYC’ed

23.
Challenges for anarchic chains
● By design anarchic / public blockchains
intentionally lack:
− Terms of Service; End-User License Agreement;
service-level agreement; consumer protections;
customer service
● They lack these contractual hooks because any
such artifact in an anarchic chain leads to some
"controller" who can be shut down

24.
Anarchic cont'd
● Regulated institutions handling regulated data
might not use an anarchic chain for a couple
reasons including:
- Because all information is replicated globally
and stored publicly and can be downloaded
by anyone allowing them to potentially learn
some kind of proprietary information
- This type of replication potentially violates
various national and supranational
regulations

25.
Challenges for permissioned chains
● In contrast, private/permissioned chains are
specifically built around contractual agreements
and tie-ins with legal infrastructure.
● The challenge is in operation and maintenance:
− SLAs: which cloud provider or 3rd party providers
should the nodes operate out of?
− How to prevent the network from becoming
centralized such that collusion or abuse could
occur? (e.g,. the problems that database have)
− How to handle disputes that span multiple
jurisdictions?

26.
Other impact of GDPR on a chain
● For a company, this impacts HR and payroll
systems more in the forefront, which typically
gets controlled by some cloud central database
solution with easy deletion.
● For a blockchain platform, this gets tough
because of right to be forgotten rules that force
deletion (unrecoverable pseudoanonymization)
or full anonymization.
● The hard part is breaking the chain of
provenance and revocation.

27.
Doomed, right?
Not all is roses for a fully chained
world

28.
● A single cloud provider could host the nodes
across multiple data centers, giving you some
fault tolerance of physical failure.
● But then you're dealing commercially with a
single party, who can 'extort' the network
participants if migration to another cloud(s) is
difficult (monopoly rent seeking).
● There are other more subtle risks to cloud, like
some unknown vulnerability in the client
software that can be exploited across the entire
network because cloud provider uses the same
hypervisor software on all its hardware.

29.
For blockchains: who sues who?
● The fact that data is stored in perpetuity is a
problem under a lot of regulators views of
perpetuity and around "purpose limitation" (you
don't collect for other purposes)
● Also limitation of retention past when the data is
useful. So keeping data forever that is not
required, that will be an issue.
● If you're a conduit of data, if you have no control
of it, you were not liable. But the bright line
between being a conduit and hosting is being
eroded.

30.
Key takeaways

31.
SFYL

32.
Also, more SFYL

33.
Other takeaways
● Data privacy issues are not inherently solved
because of the usage “blockchains”
● In fact, the opposite may be true, especially with
blockchains that use a “gossip” method and
replicate all information to every node globally.
● If you plan to build, maintain, or operate
infrastructure – including a blockchain – be sure
to have a lawyer who specializes in data privacy
to scrutinize your platform.

34.
Contact
● tim@postoaklabs.com

35.
Appendix