The Proof of Concept

Use case context

The use case context includes :

• Regulators like European Central Bank or National Central Bank
• Clearing Houses
• Banks

For now, the use case excludes :

• Bank clients (Originator and Benificiary) who could be included in a future version

Current POC architecture

Target solution architecture

Sequence diagram

List the Product stack

Key Features

• Participants can send Payment Instructions to concerned parties
• Concerned parties can receive Payment Instructions
• Allowed participants can change Payment Instruction Status
• Participants can monitor their Payment Instruction
• Each Payment Instruction File is hashed by a the smart contract function. Payment Instruction Files keep on being stored on an external database to prevent privacy conflicts and volume of data.
• Ledger records multiple Payment Instruction types like SEPA or SWIFT

Benefits & Interests

How does this use case address a change in an existing system with the proposed Blockchain solution?

• Monitoring Payments Instructions inside the network
• Facilitate Audits for Regulators like European Central Bank or National Central Bank
• Follow SWIFT/SEPA Payment Standards
• Identity Management & Payment Infrastructure Integration
• Regulation rules puts in the smart contract, reducing cost since bank don’t have to implement them in each of their IS.

Lessons Learnt/Best Practices that you'd like to share with other teams?

• Have achievable goals with high added value
• Write up-to-date wiki, make your team more efficient
• Using simple development tools like Bitbucket, Trello and Slack facilitate communication and understanding
• Make Brainstorming and illustrates your ideas with schemas
• Make constant Feed-backs with demo
• Test your chaincode with Postman
• Exchange with the stakeholder as often as possible

Is there an existing solution that can be extended by your team's solution, to address

any use case or an overall improvement?

• Integrate other payment infrastructure
• Integrate public blockchain infrastructure
• Follow other worldwide Payments Standards
• Extend solution to detect financial fraud
• Implement an IPFS Manager for Payment Instruction Files
• Chronologic Tracability of payments Instructions Status
• Automatic Payment Instruction file import to the chaincode

FAQ

Why aren't the payments stored on the Hyperledger Blockchain ?

While this could ultimately be the case (see Bitcoin), the current state of the Bank industry cannot handle as big of a change in a short period of time. The accounts and payments logic is a complex system handled differently by multiple stakeholders. For these reasons, we chose to use the Hyperledger Blockchain as a "payments state manager". There are many schemas and pages on this site explaining our solution.

Why aren't the payment files stored on the Hyperledger Blockchain ?

The Hyperledger fabric is not meant to store files. Other Blockchain implementations are specialized in this task and are probably are a better fit for that, this is why our solution only stores "references" (checksums) to the real files hosted on an other platform.

It is also worth noting that we should not let the smart contracts handle plain (as in not crypted) files, as other peers could see their potentially confidential content. For this reason, the blockchain itself (using smart contracts) cannot validate the payment files format.

Why doesn't your chaincode make external API calls to strengthen the integration with existing bank systems ?

Smart contracts must be deterministic to avoid consensus issues. This is a major problematic while designing a Blockchain system because it prevents the Blockchain from interacting with the "external" world directly.

Why isn't Interledger used ?

While Interledger was a solid tool that we could have used to design our solution, the blockchain do not carry the "true" payment informations (accounts, currencies..) for the reason cited above. As a result, Interledger cannot be used in the scope of our solution.