1. What should a user do to receive IBAN account in Dan's bank? Is a user country important?
2. Which system should be responsible for account management – IBAN generation, keeping balance, operation history?
3. Can a user, who is not registered in the Exchange, make a Fiat (Euro) transactions?
4. Should Simple trade mechanism be available for Euro?
5. Is it possible, conversion for other bank than Dan bank to Fiat (Euro)? (A user has fiat and wants cryptocurrency). Should a user be registered?
6. How will the GUI look like? Will additional authorization be required for sending Euro via Exchange interface?
1. Can a user, who is not registered in the Exchange, make a Fiat (Euro) transactions?
2. Should Simple trade mechanism be available for Euro?
3. Is it possible, conversion for other bank than Dan bank to Fiat (Euro)? (A user has fiat and wants cryptocurrency). Should a user be registered?
## Notes
### 1. CBS - central banking system.
Responsible for:
a) allocating IBAN numbers for bank customers
b) discrimination between different transfer types: internal, SEPA, non-internal non-SEPA. Internal ones should be immediately booked by the system and SEPA should be executed via DIS, while all the others should be rejected as not supported
c) executing transactions incoming from SEPA
d) quequing all transactions which cannot be sent to SEPA beacuse of limited availibility of BoL services
e) tracing transaction status (according to statuses specific to SEPA), holding account history for each account
f) holding account balances
g) exposing RPC API to the exchange providing all needed functionality for transaction scanner and transaction executor (wallet/node equivalent)
h) serving undefined reporting services determined by bank law indirectly or by interfacing other services
i) executing end-of-day actions needed to update bank total balances and do all actions required by SEPA etc.
There should be separate CBS-plugin for each fiat currency and separate instance of CBS for each fiat currency. The CBS should consist of modules responsible for e.g. managing user accounts, communication with CBS-plugin, communication with Bank, queuing transactions. It should be possible to turn off some modules.
Each CBS-plugin will have separate configuration in the Exchange that defines available functionality in CBS(e.g. opening account).
### 2. IB - Internet banking.
Allows a user to:
a. Create a transfer order
b. Check account balance
c. Check operation history (what debit or credit his account)
d. Check order history (i.e. rejected transfer order)
e. Authorize his transfer order (SMS, token, etc.)
Additionally user should have a possibility of editing his data (phone number), choose authorization and authentication method.
### 3. DIS (shortcut based on BoL documentation)
a) discrimination between different transfer types: SEPA, non-SEPA. SEPA should be executed via DIS, while all the others should be rejected as not supported
b) executing transactions incoming from SEPA
c) queuing all transactions which cannot be sent to SEPA because of limited availability of BoL services
d) tracing transaction status (according to statuses specific to SEPA), holding account history for each account
e) holding internal account balances – balances are not available for users
f) exposing RPC API to the exchange providing all needed functionality for transaction scanner and transaction executor (wallet/node equivalent)
g) serving undefined reporting services determined by bank law indirectly or by interfacing other services
h) executing end-of-day actions needed to update bank total balances and do all actions required by SEPA etc.
There should be separate EURO-client for each fiat currency and separate instance of CBS for each fiat currency. The CBS should consist of modules responsible for e.g. communication with EURO-client, communication with Bank, queuing transactions. It should be possible to turn off some modules.
Each EURO-client will have separate configuration in the Exchange that defines available functionality in CBS.
### 2. DIS (shortcut based on BoL documentation)
Consists of:
a. CDR reposible for processing documents (see more [CDR](Architecture/CDR))
a. CDR responsible for processing documents (see more [CDR](Architecture/CDR))
b. CPR responsible for processing messages (see more [CPR](Architecture/CPR))
c. XML Signature (signing and verifying a signature)
d. PAS Gateway (logging and sending signed messages to PAS)
### 4. PAS
### 3. PAS
Bank of Lithuania system managing message exchange between various bank and external systems (see more [PAS](Architecture/PAS))
## Remarks:
1. Users don’t have IBAN accounts in Dan’s bank.
2. SEPA doesn’t work all the time. SEPA works only in working days during defined working hours. CBS is responsible for queueing transactions.
## Use cases
**I. Sending cryptocurrency and receiving EURO**
...
...
@@ -51,74 +42,40 @@ Bank of Lithuania system managing message exchange between various bank and exte
**UC 1**
A Exchange user sends cryptocurrency and wants to receive Euro.
1.*An exchange user makes a transfer using the Exchange interface*
1. An exchange user makes a transfer using the Exchange interface
2. An operation in the blockchain includes a receiver IBAN account.
3. A memo description (with IBAN account) is encrypted.
4. A transaction is processed with a standard path in the Exchange:
a. The transaction scanner in the source blockchain recognizes an operation and takes an appropriate action (as now) – sends it to CBS-plugin
b. CBS-plugin or CBS recognizes whether it is an internal transfer (to IBAN account in the Dan’s bank) or external transfer (to IBAN account not in the Dan’s bank):
i. If it is internal transfer, then it is processed in CBS-plugin or CBS
ii. If it is external transfer, then it is sent to DIS - see [diagram flow](use cases/uc-2)
a. The transaction scanner in the source blockchain recognizes an operation and takes an appropriate action (as now) – sends it to CBS
b. CBS recognizes whether it is an SEPA transfer or non-SEPA transfer:
i. If it is SEPA transfer, then it is sent to DIS - see [diagram flow](use cases/uc-2)
ii If it is non-SEPA transfer, then it is rejected.
*Remarks:*
1. Everyone can send money to IBAN account and user doesn't need any access to this account.
2. SEPA doesn’t work all the time. SEPA works only in working days during defined working hours. CBS-plugin or CBS is responsible for queueing transactions.
**II. Sending EURO and receiving cryptocurrency**
**UC 2**
A Exchange user sends Euro from his IBAN account in Dan’s bank and wants to receive cryptocurrency
1. A transaction is processed with a standard path in the Exchange
2. A transaction is not processed by DIS.
3. Dan's bank accounting subsystem (CBS-plugin or CBS) stores information about reducing of user account balance.
**UC 3**
A Exchange user sends Euro from his account not in Dan's bank and wants to receive cryptocurrency.
1. DIS sends a transaction to CBS-plugin or CBS – see [diagram flow](use cases/uc-4)
To be discussed:
1. What is responsible for keeping information about balance account, info whether account is open?
*After meeting:*
*Remarks:*
*1. There is no functionality that allows to check a user account balance in cryptocurency for accounts other than Dan’s. Why? It is useless, because balance can change.*
*2. Sending Euro requires dedicated application for creating Euro transfer.*
*We can see two possible solutions for UC2 and UC3:*
*First solution:*
1.*An exchange user makes a transfer using the Exchange interface (or rather a dedicated interface of IB).*
2.*CBS registers a transaction (similarly to blockchain registering a transaction).*
3.*CBA-plugin transaction scanner checks via CBS if there are any new incoming transactions on Dan’s account (same as for any crypto/blockchain).*
4.*If there are any, CBA-plugin transaction scanner fetches those transactions and processes them (same as for any crypto/blockchain).*
*Then the standard execution path is followed in the Exchange: a record is created and processed.*
*Pro:*
-*It reduces UC2 and UC3 to the same use case.*
**UC 2**
An exchange user sends Euro from his banking account ( not in Dan's bank) and wants to receive cryptocurrency.
1. An exchange user makes an order using Exchange interface.
2. Exchange generates order id.
3. A user sends EURO to Dan’s account using generated order id as transfer title via his internet banking.
4. DIS registers a transaction.
5. DIS sends a transfer to CBS see [diagram flow](use cases/uc-4).
6. CBS registers transaction in its database.
7. EURO-client transaction scanner checks via CBS if there are any new incoming transactions on Dan’s account (same as for any crypto/blockchain).
8. If there are any, EURO-client transaction scanner fetches those transactions (served by CBS from its database) and processes them (same as for any crypto/blockchain).
*Second solution:*
1.*An exchange user makes a transfer using the Exchange interface.*
2.*The Exchange creates a record and sends it to the CBS.*
3.*CBS registers a transaction.*
4.*The Exchange processes the record.*
Then the standard execution path is followed in the Exchange: a record is created and processed.
**III. Sending Euro and receiving EURO**
**UC 4**
A Exchange user sends Euro from his account in Dan’s bank to someone account in Dan’s bank
1. Is it possible that user has more than one account in Dan’s bank?
**UC 5**
A Exchange user sends Euro from his account in Dan’s bank to an account outside Dan’s bank.
**UC 6**
A Exchange user receive Euro to his account in Dan’s bank from an account outside Dan’s bank.
It seems to be possible.
**IV. SEPA issues**
**UC 7**
**UC 3**
Cancel request
(copied form user guide)
A Debtor Agent who has initiated a credit transfer can request to cancel this credit transfer. The EPC125-05 SEPA Credit Transfer Scheme Rulebook Version 8.0 lays down the possible reasons for cancelling a credit transfer and establishes that a request for cancellation can be submitted within 10
...
...
@@ -127,4 +84,3 @@ business days of the execution of a credit transfer. The Debtor Agent, at its ow
the credit transfer, by accident, was executed twice (was duplicated); then the ISO code of the reason in the FFPCRQST document transaction must be DUPL;
was incorrect for technical reasons; then the Proprietary code of the reason in the FFPCRQST document transaction must be TECH;
was submitted by fraudulence; then the Proprietary code of the reason in the FFPCRQST document transaction must be FRAD.
