-
Notifications
You must be signed in to change notification settings - Fork 0
Use Case Trade Finance Letter of Credit
Sections in italics are optional.
A letter of credit (LoC) is a document, typically from a bank (Issuing Bank), assuring that a seller (Beneficiary) will receive payment up to the amount of the letter of credit, as long as certain documentary delivery conditions have been met.
As a Seller I want to be paid as soon as I have delivered the products according to the terms and conditions in the LoC. During the LoC contract agreement stage I want to make sure that the terms and conditions are acceptable to me.
As a Buyer I want to pay only for products that have been delivered according to the terms and conditions specified in the LoC. During the contract agreement stage I want to make sure that the terms and conditions are acceptable to me.
As an issuing banker I want to be able to verify that the seller has performed delivery according to the LoC before paying the seller.
As an advising banker I want to be able to advise the seller regarding the LoC received from the Issuing bank during the contract agreement, and conveys the delivery documents from the Seller to the Issuing bank, and accepts payment from the issuing bank for the Seller.
Usage Scenario Examples
-
The Buyer finds a Seller/Supplier and executes a sales contract or pro forma invoice. The Buyer and Seller agree on the terms and conditions to be included in the LoC
-
The Buyer applies to the Issuing bank for a LoC in favor of the Seller with the agreed upon terms and conditions.
-
The issuing bank prepares an LoC and sends it to the Seller's bank aka advising bank.
-
The advising bank verifies authenticity of the LoC and advices the Seller on the terms and conditions in the LoC
-
Seller verifies the terms and conditions and if there are no discrepancies goes about supplying and delivering according to the agreement. If there are discrepancies Seller informs the Buyer to fix them.
-
On completing shipment/delivery, the Seller obtains the delivery documents specified in the LoC and gives it to the advising bank.
-
The advising banks sends the documents to the issuing bank.
-
The issuing banks verifies that the delivery documents satisfy the terms and conditions specified and if acceptable it sends payment to the Seller via the advising bank.
-
The issuing bank collects payment from Buyer, and provides the delivery documents to the Buyer.
Problem Definition
The process today is highly manual and requires the reconciliation between several independent records on each entity involved - Buyer, Issuing Bank, Advising Bank, Seller. The Blockchain could be the shared source of truth and work-flow engine to automate the process and provide cryptographic proof if actions and performance.
Related User Stories or Problems
"NONE".
Opportunity/Justification
This section is mandatory.
Use this section to give opportunity details that support why pursuing these user stories would help address key barriers to adoption or operation.
Some examples of information that might be included here are applicable market segments, workloads, user bases, etc. and any associated data.
Requirements
This section is mandatory, but only top level sections need to be answered.
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.
Legal Association — legal and structural requirements of federation members, and how the enter (and exit) the 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).
Transaction ordering - UTXO / transaction stream.
Correctness Requirements:
Requirement for external or trusted third-party?
Dispute resolution (internal to federation, say by vote or penalty, or external, say by assocation, 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).
Consensus protocol: Proof of Work, Proof of Stake, Open Federation, provable BCP, Stellar Consensus, RAFT/PAXOS.
Proof of Publication/Existence Timestamp: (how precise? to multiple blockchains?).
Finality - how long does it take for a transaction to become irreversible? This could have both time and probability of irreversiblity constraints.
Privacy requirements:
Consensus Makers - permissionless, censorship resistent, permissioned, open federation, closed federation.
Delegation - Do participants need to delegate permissions/secrets, and if so, how?
Identification - Permissioned to Pseudoanonymous, non-correlatable (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).
Biometric Privacy - Are there extra security requirements for particularly sensitive information?
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.
Hardware Requirements
Biometric Authentication
Embedded Execution / Trusted Hardware? Ring 0, 1, 2?
Others Use Cases with Similar Requirements
External References
This section is mandatory, but may be NONE.
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.
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.
Rejected User Stories / Usage Scenarios
This is optional.
Please fill out this section after a User Story has been submitted as a cross project spec to highlight any user stories deemed out of scope of the relevant cross project spec.
Glossary/Appendices
This section is optional.
It is highly suggested that you define any terms, 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 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.
Remember: The better you communicate your user story, the more likely it is to be considered by the project teams and the product working group.
Examples:
reST reStructuredText is a simple markup language TLA Three-Letter Abbreviation is an abbreviation consisting of three letters xyz Another example abbreviation