1. BCINED | 05-09-2017
Treasury banking
using a blockchain
Summary of our pilot project,
questions, answers and plans.
Christian C. Schouten
2. Allow me to introduce myself
• Christian Schouten
• Contact details on last sheet
• Ministry of Finance, Dept. National Budget
• Programme: “Roadmap to a digital budget”. Improving the national
government’s financial information using new technologies.
• Blockchain has been identified there as a long term goal (5-10 years).
• So far, no less than 27 gov’t organisations
have been collaboratively investigating
the possible uses of blockchain technology
(see website).
3. Treasury pilot: summary
• Starting thought: if it can manage bitcoins, can it manage euros?
• Use case: granting a treasury loan for a new building to a school.
• Parties involved: Ministry of Finance (policy and agency), Ministry of
Education, City Council, gov’t CIO offices, internal gov’t auditors,
audit court etc. School intentionally left hypothetical.
• Execution: develop a process description that encompasses all
parties involved and then translate this into functioning prototype.
• One integrated system for all.
• Total budget all-in: €15k
4. Learning objectives
• Exploring the (im)possibilities of smart contracts (automated
contracting).
• Exploring the (im)possibilities of cryptocurrency (digital money). Can
the euro for instance be programmed to allow only building
expenses?
• Exploring the impact of having a shared information set. Can
administrative relief and simplified accountability be made possible?
• Critical assessment of usefulness of legacy systems.
• Exploration of security, inventory of risks.
5. Process steps (1)
• Step 1: School asks MofEd for a loan to realise a new building.
• Step 2/3: Upon approval by MofEd, treasury is asked to draft the
paperwork.
• Step 4: Treasury grants the loan, cryptobudget is created and euros
transferred.
• Step 5: School selects a contractor for the work.
• Step 6/7: Contractor’s invoices are matched with the school’s
cryptobudget.
• Step 8: Contractor’s invoices are paid in euros.
9. Smart contracts
• The smart contract effectively summarizes the entire process, all
conditions placed on the loan, into a single ‘contract’.
• This includes amongst others:
• “Has consensus been reached on expected student numbers?”
• “Has city council agreed to warrant the loan?”
• Loopback from education dept. to treasury that all relevant
departments have signed off on the loan.
• Plus of course the loan’s repayment schedule.
10. Cryptocurrency (TreasuryCoin)
• Treasury vs. school
• Loan is applied for in euros
• Loan is granted as a cryptobudget
• Loan is paid back in euros
• School vs. contractor
• Invoicing in euros with cryptobudget-reference
• Matching with cryptobudget
• Payment in euros
11. Plans in the (near) future
• Evaluation report on this pilot about to be published.
• In general: broad applicability, chances with procure-to-pay, loans
and grants, budgets and actuals.
• Primary focus: smart contracts to optimize gov’t financial processes
• Secondary focus: cryptocurrency. More control over expenses, but
outside of monetary system. Currently. Should this be harmonised?
• Verantwoording
• Two projects to follow up:
– Project “A” to build the first production blockchain in government (that I am aware
of…), modeling treasury processes in a simple(!) use case, then adding onion rings
– Project “B” to further explore accountability and control questions in a setting that
is relevant to society and relatable to a large audience (because A is not sexy…)
13. Vraag 1
• Hoe kunnen we zeker weten dat het smart contract 1-op-1 synchroon
loopt met wet- en regelgeving?
– Zodra iets geprogrammeerd is, is het eigenlijk een soort black box. Voor de
gebruiker/eigenaar niet meer eenvoudig te controleren. Toch is deze
verantwoordelijk voor de taakuitoefening. Als alles goed gaat ben je automatisch
compliant, maar ergens is er nog een onderbuikgevoel van iemand op zijn blauwe
ogen moeten geloven. Probeer een handreiking te verzinnen hoe te bewijzen dat
smart contract en wet- en regelgeving volledig identiek zijn (en de uitvoering dus
compliant).
14. Vraag 2
• Hoe kunnen we zeker weten dat de financiële processen ook met
nieuwe technologieën gestroomlijnd blijven?
– Eenmaal geautomatiseerd en in productie genomen is het wellicht verleidelijk dit
deel van de financiële processen als ‘fait accomplis’ te beschouwen en niet meer na
te denken over de vraag of dit systeem nog wel het hogere doel dient. Het systeem
is niet leidend, de wet- en regelgeving is dat, met daarin opgenomen wat het proces
zou moeten opleveren. Hoe kunnen we nu voorkomen dat na wijzigingen of bij
nieuwe inzichten en/of mogelijkheden een nieuw systeem hetzelfde lot ondergaat
als andere/eerdere systemen en tot in lengte van dagen (vrijwel) ongewijzigd een
inefficiënte uitvoering blijft bieden aan haar gebruikers?
15. Vraag 3
• Hoe kunnen we ondanks de dubbeling tussen cryptocurrency en
euro toch in control blijven?
– Elke euro wordt in dit voorbeeld twee maal geadministreerd. Eenmaal in de eigen
blockchain-systemen, oftewel als SchatkistCoin, en eenmaal als ‘echte’ euro bancair
overgeboekt. Immers, het administreren in de eigen valuta maakt dit systeem nog
niet geaccepteerd door externe partijen. Logischerwijs kan hier beredeneerd worden
dat dit zomaar een keertje mis zou kunnen gaan en de crypto-registratie resp. de
overboeking uit elkaar uit elkaar zouden kunnen lopen. Hoe kunnen we dit risico
afdekken? Hoe voel ik me als klant in control dat deze fout niet gaat gebeuren?
16. Vraag 4
• Hoe kunnen we een vereenvoudigde verantwoording vormgeven
samen met de ADR en de AR?
– Door het smart contract volledig 1-op-1 te laten lopen met wet- en regelgeving en
het proces compleet te automatiseren is de uitvoering per definitie compliant. Een
traditionele controle is dan effectief overbodig omdat de gebruiker niet van het pad
van compliancy kan afwijken. Het ligt dan voor de hand om de controle meer te
verschuiven naar de ‘voorkant’ van het proces, waarbij de ADR kijkt of het proces
compliant is ingericht. Hoe zou dit in concreto vormgegeven kunnen worden?
17. Vraag 5
• Hoe kunnen we een succesvolle implementatie van 1 proces op een
alternatief platform richting een productiesituatie brengen?
– Het moge duidelijk zijn dat de casus in deze pilot een ideale kandidaat was en dat
de pilot ook goed is uitgevoerd. Maar tegelijkertijd, we hebben expres de pilot van
tevoren ingekaderd om pilot te blijven. Hoe kunnen we nu hiervan leren om – in het
algemeen – dit soort processen te ondersteunen met blockchaintechnologie? Waar
moeten we rekening mee houden als we een productiesituatie optuigen?
18. Blockchain: wat is het?
• Van de bitcoin gebruiken wij niet de valuta maar wel de
onderliggende technologie. Die heet ‘blockchain’.
• Een blockchain is, in essentie: een gezamenlijk door meerdere
partijen bijgehouden register van transacties. wie is de eigenaar?
• Oneerbiedig gezegd: blockchain is (oorspronkelijk) de backend voor
bitcoin zoals een internetbankier-app ook een backend heeft.
• Blocks van transacties worden door alle knooppunten uit het
netwerk geanalyseerd op correctheid en consistentie.
• Nadat het netwerk het er over eens is dat dit een ‘goede’ transactie
is, is dit onwijzigbaar. Zo wordt bewerkstelligd dat elke partij in het
netwerk over dezelfde informatie beschikt en wordt frauduleuze
tussenkomst onmogelijk gemaakt. wat nu als er iets mis gaat?
19. Processtappen (3)
• Voorgaande twee sheets waren wellicht wat abstract.
• Probeer nu eens de vergelijking te maken met een eigen
hypotheekverstrekking:
• De school is een starter die zijn eerste huis koopt
• De gemeente zijn de ouders die garant staan
• De aannemer doet de verbouwing en wordt gefinancierd uit het
bouwdepot
• De AFM houdt toezicht, stelt kaders op de financiële markt
• De bank verstrekt de lening
20. Smart contracts (2)
• Je gaat dus automatisch een contract aan,
• Op basis van alle gestelde voorwaarden, wet- en regelgeving.
• Vraag: is dit contract bindend?
• Door je transactie te standaardiseren en ook je proces,
• En door je relevante gegevens te delen met betrokken partijen,
• Verhoog je de accuratesse van resultaten en data tot een maximum,
• Vervalt de noodzaak voor bijvoorbeeld controle en verantwoording,
• Zonder deze noodzaak kunnen stappen ook weggesneden worden,
• Dit levert tijds- en geldwinst op (geen infra meer nodig bijv.).
• Vraag: wat als er een programmeerfoutje in zit? Wie is aansprakelijk?
• Staat of valt met basis van vertrouwen: onfeilbaar, immuteerbaar etc.
21. Cryptocurrency (2)
• Geld wordt dus aangevraagd in euro’s en verstrekt in crypto (èn euro)
• Het “creëren” van geld in de blockchain dat betrekking heeft op een
terugbetaalverplichting in euro's, is dat een dubbeling?
• Intuïtief: dat moet toch geharmoniseerd kunnen?
• Nee dus, nog niet met huidige techniek/afspraken
• Wat is nu de wet- en regelgeving (c.q. financieel stelsel/garantie)
rondom cryptocurrency? Ontbreekt het? Past het in huidige teksten?
• Vraag: moet er toegespitste regelgeving komen? Moeten we
überhaupt iets regelen?
22. Belang
• Als stappen (zoals verantwoording) worden ‘weggeautomatiseerd’:
• Minder bureaucratie (geen natte handtekeningen, versiebeheer, stukken per
post/mail etc.)
• Hogere kwaliteit en accuratesse van procesgang en procesdata
• Controles geautomatiseerd, daardoor minder werk
• Tijd voor deze activiteiten valt dus vrij (sneller eindresultaat)
• Vrijvallen (externe) uren betekent ook direct minder kosten
• Doorkijk naar nut/noodzaak informatiesystemen (IRC/LEDA)
• Vrijvallen hiervan zou ook kapitaal vrijmaken (infra, licentie, advies en beheer)
• Veiligheidsrisico: wie zit er daadwerkelijk achter de pc?
23. Uitleg (1)
• De blockchain is expres ontworpen als een rekenintensief proces met de
bedoeling de stroom aan nieuwe blocks op een constant tempo (één per tien
minuten) te houden. Bij de eerste implementatie van een blockchain, voor de
bitcoin, is namelijk aan het ‘afmaken’ van een block ook de uitgifte van
nieuwe bitcoins gekoppeld. De bitcoin-blockchain probeert zo de creatie van
bitcoins te reguleren gelijk een centrale bank een rol speelt bij de uitgifte van
fysieke valuta. Deze moeilijke rekensom wordt gepubliceerd als een
tekenreeks waar de oplossing mee moet beginnen. De oplossing is dan een
hash, een versleuteling van het origineel dat begint met deze doelwaarde (het
target). Een hash is namelijk eenrichtingsverkeer: van een origineel kan wel
een hash worden berekend, maar van een hash kan het origineel niet worden
gereconstrueerd. Het is daarom een gangbare manier om aan te geven dat
iets origineel is en niet kwaadwillend gewijzigd.
24. Uitleg (2)
• De miners krijgen dus het originele block te zien tezamen met de
doelwaarde. Zij gaan elk individueel nu willekeurige versleutelingen
(nonce) proberen om maar een versleuteling te krijgen die begint
met de doelwaarde. Wanneer er een oplossing voor dit probleem is
gevonden stuurt de gelukkige miner zijn oplossing (proof of work)
door naar de andere miners die de juistheid ervan verifiëren. Bij
instemming wordt het block als waarheid aanvaard.
25. Uitleg (3)
• Een voorbeeld:
• Als block veronderstellen we de zin “Hello, world!”.
• Het target is een hash die begint met “000”.
• De hash van het block met nonce 0 is “1312af17(…)ec934c64”. Deze
oplossing voldoet dus niet aan het target.
• Hash bij nonce 1 is “e9afc424(…)9332a7d8” en voldoet dus niet.
• Hash bij nonce 2 is “ae37343a(…)fd4266d7” en voldoet dus niet.
• (…)
• Hash bij nonce 4249 is “c004190b(…)26ebb9e6” en voldoet dus niet.
• Hash bij nonce 4250 is “0000c3af(…)12dcd4e9” en voldoet wel.
• De miner stuurt zijn proof of work rond in het netwerk.
• De andere deelnemers verifiëren zijn oplossing en stemmen in.