1. What should a user do to receive IBAN account in Dan's bank? Is a user country important?
2. Czy użytkownik, który nie jest zarejestrowany w Exchangu, może dokonywać operacji na Euro.
3. Czy mechanizm simple trade powinien być dostępny dla fiatów?
4. Czy dopuszczamy konwersja z banku innego niż Dan na krypto?
5.
**UC 1**
A Blockchain user sends cryptocurrency and wants to receive Euro(beetwen own accounts).
*Initial condition:* A user has an account number in Dan’s bank.
It is outside SEPA.
*Remark*: Everyone can send money to IBAN account and user doesn't need any access to this account.
1. Operacja w blockchaine zawierać docelowy IBAN.
2. Opis w memo ( w tym IBAN) jest niejawny (zaszyfrowane).
3. Standardowa ścieżka przetwarzania transakcji w Exchangu: skaner transakcji w źródłowym blockchainie rozpoznaje operacje i podejmuje odpowiednie akcje - jak obecnie, przekazując je do SEPA-plugin. SEPA-plugin jest odpowiedzialny za rozpoznanie numeru IBAN (jako jako zewnętrzny lub wewnętrzny) i podjęcie odpowiednich akcji z DIS.
4.
Jeżeli przelew jest wewnętrzy - to wewnętrzne mechnizmy exchanga.
Jeżeli przelew jest zewnętrzny -
5. Mogą przyjść zlecenia w godzinach, w których Sepa nie działa. Sepa-plugin jest odpowiedzalny za kolejkownaie transakcji.
**UC 2**
A Blockchain user sends cryptocurrency and wants to receive Euro .
*Initial condition:* A user doesn’t have an IBAN account number in Dan’s bank.
There are following operations:
1. In the Blockchain:
Transfer cryptocurrency from user's account into Dan's account
2. In the SEPA:
Transfer Euro from Dan’s account to user account.
Detail description of point 2 see on the [diagram flow](use cases/uc-2)
**UC 3**
A Blockchain user sends Euro from his account in Dan's bank and wants to receive cryptocurrency.
*Initial condition:* A user has an account number in Dan’s bank.
It is outside SEPA.
*Remark*:
1.
**UC 4**
A Blockchain user sends Euro and wants to receive cryptocurrency.
*Initial condition:* A user doesn’t have an account number in Dan’s bank.
There are following operations:
1. In the SEPA
Transfer Euro from user account to Dan’s account
2. In the Blockchain:
Transfer cryptocurrency from Dan’s account into user’s account.
Detail description of point 1 see on the [diagram flow](use cases/uc-4)
**UC 5**
A Blockchain user sends Euro and wants to receive Euro.
*Initial condition:* A sending account is in Dan’s bank.
There are following operations:
1. In the Blockchain (to know what the balance is)
Transfer Euro from user's account in Dan’s bank into Dan's account
2. In the SEPA
Transfer Euro from user's account in Dan’s bank into receiver account
*Remarks:
I am not sure how it should be visible from SEPA point of view – the sender should be Dan or a user.*
**Meeting summary – 14.01.2019**
**Questions**
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?
**I. Sending cryptocurrency and receiving EURO**
**UC 1**
A Exchange user sends cryptocurrency and wants to receive Euro.
1. An operation in the blockchain includes a receiver IBAN account.
2. A memo description (with IBAN account) is encoded.
3. 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 SEPA-plugin
b. SEPA-plugin or Something between SEPA-plugin and DIS 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 SEPA-plugin or Something between SEPA-plugin and DIS
ii. If it is external transfer, then it is sent to DIS - see [diagram flow](use cases/uc-2)
*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. SEPA-plugin or Something between SEPA-plugin and DIS is responsible for queueing transactions.
**To be discussed during next meeting:**
**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. Somewhere (SEPA-plugin or Something between SEPA-plugin) is stored 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 SEPA-plugin or Something between SEPA-plugin – 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?
**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 Blockchain user sends Euro and wants to receive Euro.
*Initial condition:* A receiving account is in Dan’s bank.
There are following operations:
1. In the SEPA
Transfer Euro from user's account into user account in Dan's bank
2. In the Blockchain
Transfer Euro from Dan's account into user's account in Dan’s bank.
A Exchange user receive Euro to his account in Dan’s bank from an account outside Dan’s bank.
**UC 7**
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
business days of the execution of a credit transfer. The Debtor Agent, at its own or its client initiative, can submit a request for cancellation for FFPCRQST document transactions, where:
**UC 7**
Someone sends Euro to a blockchain user account in Dan’s bank (outside blockchain)
There are following operations:
1. In the SEPA
From user Euro account to user Euro account in Dan’s bank
2. In the Blockchain
From Dan’s Euro account to user Euro account in Dan’s bank.
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.
**UC 8**
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
business days of the execution of a credit transfer. The Debtor Agent, at its own or its client initiative, can submit a request for cancellation for FFPCRQST document transactions, where:
- 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.
