User Tools

Site Tools


requirements:use-cases:use-case-interest-rate-swap

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

requirements:use-cases:use-case-interest-rate-swap [2016/11/01 15:08]
Jeremy Sevareid created - migrated from legacy github wiki
requirements:use-cases:use-case-interest-rate-swap [2016/11/02 17:26] (current)
Jeremy Sevareid Amend - fixed legacy wiki formatting
Line 1: Line 1:
-FIXME+====== Use Case Interest Rate Swap ======
  
-# Use Case Interest Rate Swap+===== Section 1 - Intro =====
  
-## Section 1 - Intro +==== Overview of the Business Problem or Opportunity ​====
- +
-### Overview of the Business Problem or Opportunity+
  
 Interest Rate swaps help borrowers hedge the risk of changing interest rates. The parties to an interest rate swap contract agree to exchange interest rate cash flows. Interest Rate swaps help borrowers hedge the risk of changing interest rates. The parties to an interest rate swap contract agree to exchange interest rate cash flows.
Line 15: Line 13:
 In return for matching the two parties together, the bank takes a spread from the swap payments. In return for matching the two parties together, the bank takes a spread from the swap payments.
  
-<​p><​a href="​https://​commons.wikimedia.org/​wiki/​File:​Vanilla_interest_rate_swap_with_bank.png#/​media/​File:​Vanilla_interest_rate_swap_with_bank.png"><​img src="https://​upload.wikimedia.org/​wikipedia/​commons/​8/​81/​Vanilla_interest_rate_swap_with_bank.png" alt="​Vanilla interest rate swap with bank.png"​ height="​315"​ width="​640"></​a><​br>​By <a href="//​commons.wikimedia.org/​w/​index.php?​title=User:​Suicup&​amp;​action=edit&​amp;​redlink=1"​ class="​new"​ title="​User:​Suicup (page does not exist)">​Suicup</​a>​ - <span class="​int-own-work"​ lang="​en">​Own work</​span>,​ <a href="​http://​creativecommons.org/​licenses/​by-sa/​3.0"​ title="​Creative Commons Attribution-Share Alike 3.0">​CC BY-SA 3.0</​a>,​ https://​commons.wikimedia.org/​w/​index.php?​curid=7195752</​p>​+{{https://​upload.wikimedia.org/​wikipedia/​commons/​8/​81/​Vanilla_interest_rate_swap_with_bank.png}}
  
-### Current Solution+Graphic by User: Suicup: Own work: [[http://​creativecommons.org/​licenses/​by-sa/​3.0|Creative Commons Attribution-Share Alike 3.0]]:​[[https://​commons.wikimedia.org/​w/​index.php?​curid=7195752|CC BY-SA 3.0]] 
 + 
 +==== Current Solution ​====
  
 Swap contracts serve the mutual benefit of the parties but require trusted intermediaries like investment bankers to accept and forward payments. If there were other means to provide discovery and trust, parties to a swap contract would have liked to eliminate the third party and not pay the spread. Swap contracts serve the mutual benefit of the parties but require trusted intermediaries like investment bankers to accept and forward payments. If there were other means to provide discovery and trust, parties to a swap contract would have liked to eliminate the third party and not pay the spread.
Line 23: Line 23:
 An opportunity exists to replace the intermediaries by other mechanisms that provide trust to the parties of a swap contract. An opportunity exists to replace the intermediaries by other mechanisms that provide trust to the parties of a swap contract.
  
-### Why Distributed Ledger ​technology?+==== Why Distributed Ledger ​Technology====
  
 Trust between parties to a swap contract can be provided by a distributed ledger. Borrowers can join the ledger after passing a credit check, advertise their need for a swap, discover a counterparty,​ and entrust the exchange of their loan payments to a smart contract. Trust between parties to a swap contract can be provided by a distributed ledger. Borrowers can join the ledger after passing a credit check, advertise their need for a swap, discover a counterparty,​ and entrust the exchange of their loan payments to a smart contract.
  
-### User Stories+==== User Stories ​====
  
-#### Actors+=== Actors ​===
  
-* Borrower: a company interested to swap loan payments +  ​* Borrower: a company interested to swap loan payments 
-* Administrator:​ an entity running credit check of prospective participants +  * Administrator:​ an entity running credit check of prospective participants 
-* Escrow: a legal entity whose purpose is to +  * Escrow: a legal entity whose purpose is to 
-   ​* hold a bank account +    * hold a bank account 
-   ​* notify the ledger of payments received +    * notify the ledger of payments received 
-   ​* disburse payments on command from the ledger+    * disburse payments on command from the ledger
  
-#### Stories+=== Stories ​===
  
 Swap is initiated Swap is initiated
  
-* Borrower takes out a fixed rate loan but wants to change its rate to floating +  ​* Borrower takes out a fixed rate loan but wants to change its rate to floating 
-* Borrower applies to join the interest swap ledger. Administrator runs a credit check and issues credentials. +  * Borrower applies to join the interest swap ledger. Administrator runs a credit check and issues credentials. 
-* Borrower queries the ledger for a counterparty with a matching loan but with a floating rate +  * Borrower queries the ledger for a counterparty with a matching loan but with a floating rate 
-* Parties agree to the terms and register their swap with the ledger+  * Parties agree to the terms and register their swap with the ledger
  
 Loans are repaid Loans are repaid
  
-* Every month on the agreed payment day Borrower A sends its loan payment to Escrow. The amount of the payment is calculated by the floating rate of the Borrower B's loan.  +  ​* Every month on the agreed payment day Borrower A sends its loan payment to Escrow. The amount of the payment is calculated by the floating rate of the Borrower B's loan.  
-* Escrow notifies the ledger. +  * Escrow notifies the ledger. 
-* Borrower B sends its payment to Escrow which in turn notifies the ledger. The amount of the payment is calculated by the fixed rate of Borrower A's loan.  +  * Borrower B sends its payment to Escrow which in turn notifies the ledger. The amount of the payment is calculated by the fixed rate of Borrower A's loan.  
-* Upon receipt of both notifications from Escrow, a smart contract on the ledger commands the Escrow to release the payments. +  * Upon receipt of both notifications from Escrow, a smart contract on the ledger commands the Escrow to release the payments. 
-* Escrow pays the lenders: the monthly installment of Borrower A with the money payment of Borrower B and vice versa.+  * Escrow pays the lenders: the monthly installment of Borrower A with the money payment of Borrower B and vice versa.
  
 Borrower defaults Borrower defaults
  
-* Borrower A sends its monthly payment to Escrow. Escrow notifies the ledger. +  ​* Borrower A sends its monthly payment to Escrow. Escrow notifies the ledger. 
-* Borrower B does not send its payment. +  * Borrower B does not send its payment. 
-* At the end of the payment day the smart contract does not have a notification of B's payment. The contract commands Escrow to return the A's payment. +  * At the end of the payment day the smart contract does not have a notification of B's payment. The contract commands Escrow to return the A's payment. 
-* Borrower A pays his own's loan installment with the money returned. +  * Borrower A pays his own's loan installment with the money returned. 
-* Borrower A queries the ledger for a new counterparty to continue the swap.  +  * Borrower A queries the ledger for a new counterparty to continue the swap.  
-* Borrower B is banned from the ledger. +  * Borrower B is banned from the ledger.
- +
-### Opportunity/​Justification +
- +
-* Distributed ledger provides a mechanism of trust without a need for a third party +
-* Permissioned ledger allows only the participants that passed credit check +
-* Fees are reduced to a minimum needed to maintain one Escrow legal entity for all members of the ledger +
-* Default on a swap contract is resolved immediately on the ledger and exposes the borrower only to a few days of interest rate fluctuation +
- +
-*** +
- +
-## Section 2 - States and Transactions +
- +
-#### States +
- +
-* Bid for a swap. A borrower advertises on the ledger its need for a swap with basic parameters: principal, rate. +
-* Swap contract. Both parties record the terms of their contract: loan parameters and an agreed upon payment date. +
-* Payment record. A smart contract on the ledger records each party'​s monthly payment upon notification from Escrow. +
- +
-#### Transitions +
- +
-* Bid is deactivated when parties are matched and enter into a Contract. +
-* Payment record is created by the smart contract upon notification from Escrow. +
-* When both party'​s monthly payments are recorded the smart contract notifies Escrow to release the payments. +
-* Contract is deactivated at the end of the contract term. +
- +
-*** +
- +
-## Section 3 - Requirements +
- +
-> [COMMENT: This version is probably only 40% of the potential requirements that we need to cover. Mostly here are cryptographic security and privacy requirements,​ and it is missing a number of fintech, legal and policy requirements. {CA}] +
- +
-> It is useful to specify requirements that should be considered but may not be apparent through the user story and usage examples. ​ This information will help the developers be aware of any additional known constraints that need to be met for adoption of the newly implemented features/​functionality. ​ Precise specifications of the requirements make a developer'​s job much easier, so when in doubt, consult a technical expert. +
-  +
-> Use this section to define the functions that must be available or any specific technical requirements that exist in order to successfully support your use case. If there are requirements that are external to this group, note them as such. +
-Please always add a comprehensible description to ensure that people understand your need.  If technical requirements go beyond the scope of a user story (i.e. cryptographic signatures with very unique requirements),​ feel free to add references or supplemental technical material. +
- +
-> Explain why these requirements are needed for your user story +
- +
-```` +
-* General Requirements +
-* Correctness Requirements +
-* Privacy Requirements +
-* Hardware Requirements +
-* Others Use Cases with Similar Requirements +
-```` +
- +
-* General Requirements:​ +
- +
- * Blockchain Specifics - Amount/type of block chains needed, or interaction with legacy block chains. +
- +
- * Federation Size - Number of parties involved in a single blockchain federation. [COMMENT: Is this a requirement about the number/​ratio of independent validating/​non-validating peers? {OVD}] +
- +
- * Legal Association — legal and structural requirements of federation members, and how the join/leave a federation (for instance entrance bonds or exit costs may be required to avoid sybil attacks). +
- +
- * Transaction Group Size - Number of parties involved in a blockchain transaction. +
- +
- * Connectivity / transaction frequency (bandwidth / latency). [COMMENT: Is this a requirement for validating, non-validating peers and clients? {OVD}] +
- +
- * Transaction ordering - UTXO / transaction stream. [COMMENT: Is this a requirement about the strict and best effort ordering of transactions?​ This could end-up with requirements on time synchronization for the validating/​non-validating peers. {OVD}] +
-  +
- * Public / Private blockchain access [COMMENT: This is connected to "​Privacy requirements -> Blockchain publication (public, only auditors, blinded, private)"​ {OVD}] +
- +
- * On-chain and/or off-chain data  +
- +
- * Expected lifetime of the blockchain [COMMENT: related also to audit requirements {OVD}] +
-  +
- * Storage and back-up of the blockchain [COMMENT: related to the Public vs Private blockchain {OVD}] +
- +
- * Transaction aggregation (Information retrieval including export of aggregated transactinos) requirements from the blockchain  +
- +
-* Correctness Requirements:​  +
- +
-  * Dispute resolution (internal to federation, say by vote or penalty, or external, say by association,​ mediation, arbitration or law). +
- +
-  * Bad Actor / Sybil Attack Resistance level? Mitigation approaches? Policy embodied in code or by contract law? +
- +
-  * Audit requirements - (for instance, with HD keys you need the private deterministic chain code in order to successfully audit a public key account). Audit: mechanisms to allow continuous / per-request verification of the content by external or trusted third-party?​ [COMMENT: Is it the main purpose the third party to perform audit on the correctness?​ {OVD}] +
- +
-  * Consensus protocol: Proof of Work, Proof of Stake, Open Federation, provable BCP, PBFT, Stellar Consensus, RAFT/​PAXOS.[COMMENT:​ these are not requirements,​ requirement should focus on "​what"​ not "​how"​ {FL}] +
- +
-  * Proof of Publication/​Existence Timestamps: (how precise? to multiple blockchains?​). [COMMENT: ​ This could end-up with requirements on time synchronization for the validating/​non-validating peers. {OVD}] +
- +
-  * Timing requirements for transactions to become irreversible or to be included in the ledger. This could have both time and probability of irreversibility constraints. +
- +
-* Privacy requirements:​ +
- +
-  * Consensus Makers - permission-less,​ censorship resistant, permissioned,​ open federation, closed federation.[COMMENT:​ To my understanding HPL will focus on Permissioned blockchain first, and potentially support Permissionless later. So there should be two separate requirements on Consensus maker - 1) requirements for "​Permissioned"​ blockchain, 2) requirements for "​Permissionless"​ blockchain {FL}] +
- +
-  * Delegation - Do participants need to delegate permissions/​secrets,​ and if so, how? +
- +
-  * Identification - Permissioned to Pseudo-anonymous,​ non-correctable (selective disclosure?​),​ groups. +
- +
-  * Signatures: simple signatures, single signature multiple authentication,​ multi-signatures,​ threshold signatures, smart signatures (signatures with various functional signing properties ranging from basic to extremely complex), accountability (know who voted, or to not know who voted for a threshold). +
- +
-  * Revocation or Short-term authentication?​ +
- +
-  * Separate signature vs. encryption keys? +
- +
-  * Wallet requirements?​ Hardware only, etc. +
- +
-  * Hierarchical Deterministic Keys? +
- +
-  * Blockchain publication (public, only auditors, blinded, private). +
- +
-  * Separate signatures and transactions?​+
  
-  * Privacy domains (aka who needs to see or not see signatures, contracts, transactions,​ consensus).+==== Opportunity/​Justification ====
  
-  * Biometric Privacy - Are there extra security requirements ​for particularly sensitive information?​+  * Distributed ledger provides a mechanism of trust without a need for a third party 
 +  * Permissioned ledger allows only the participants that passed credit check 
 +  * Fees are reduced to a minimum needed to maintain one Escrow legal entity for all members of the ledger 
 +  * Default on a swap contract is resolved immediately on the ledger and exposes the borrower only to a few days of interest rate fluctuation
  
-  * Level of cryptographic computation (from low to high) to support the above correctness and privacy requirements:​ basic cca encryption, blinded, multi-party computation,​ homomorphic encryption/​signatures,​ functional encryption/​signatures with desired level of functionality and other properties.+----
  
-  * Level of general "smart contract"​ computation requirements to support the above correctness ​and privacy requirements:​ none, signature verification only, smart signatures (and/or), bitcoin script level, intermediary level, Turing complete language.+===== Section 2 - States ​and Transactions =====
  
-* Hardware Requirements+=== States ===
  
-  * Biometric Authentication +  * Bid for a swap. A borrower advertises on the ledger its need for a swap with basic parameters: principal, rate. 
-   +  ​* Swap contract. Both parties record the terms of their contract: loan parameters and an agreed upon payment date. 
-  * Embedded Execution / Trusted Hardware? Ring 0, 1, 2?+  * Payment record. A smart contract on the ledger records each party'​s monthly payment upon notification from Escrow.
  
-* Others Use Cases with Similar Requirements+=== Transitions ===
  
 +  * Bid is deactivated when parties are matched and enter into a Contract.
 +  * Payment record is created by the smart contract upon notification from Escrow.
 +  * When both party'​s monthly payments are recorded the smart contract notifies Escrow to release the payments.
 +  * Contract is deactivated at the end of the contract term.
  
-### External References+----
  
-> Please use this section to add references for standards or well-defined mechanisms. ​  In particular, if any of your requirements specifically call for the implementation of a standard or protocol or other well-defined mechanism, use this section to list them. +===== Section 3 Requirements =====
  
-> Additionally,​ if your use case needs non-standard consensus mechanisms or cryptographic tools, please include technical material here, or references to technical material (i.e. a link to an eprint paper with security proofs). ​ Remember, the burden of proof for security or consensus of non-standard mechanisms will be placed upon the proposer rather than the evaluator of the proposal, so be verbose here if necessary.+TBD
  
-### Glossary/​Appendices+==== External References ====
  
-> It is highly suggested that you define any terms, +TBD
-abbreviations that are not   ​commonly used in order to ensure +
-that your user story is understood properly.+
  
-> Provide a list of acronyms, their expansions, and what they actually mean in +==== Glossary/​Appendices ====
-general language here. Define any terms that are specific to your problem +
-domain. If there are devices, appliances, or software stacks that you expect to +
-interact with Hyperledger,​ list them here.+
  
 +TBD
  
-*** +---- 
-Acknowledgement:​ This is very loosely based on the OpenStack [use case template](https://​github.com/​openstack/​openstack-user-stories/​blob/​master/​user-story-template.rst)+Acknowledgement:​ This is very loosely based on the OpenStack [[https://​github.com/​openstack/​openstack-user-stories/​blob/​master/​user-story-template.rst|use case template]]
requirements/use-cases/use-case-interest-rate-swap.txt · Last modified: 2016/11/02 17:26 by Jeremy Sevareid