bisq-network / growth

Bisq exchange growth experiments
https://bisq.wiki/Growth_team
24 stars 11 forks source link

SBP Faster payments CBRF (RUB) #288

Open skaunov opened 5 months ago

skaunov commented 5 months ago

This is a page for discussion and tracking definition for https://www.cbr.ru/eng/psystem/sfp/.

Below the line is the template filled with info. Find below the requirements assessment table. Next step is to define https://github.com/bisq-network/growth/issues/206#issuecomment-824355067?


Payment methods are evaluated very carefully before being added to Bisq. Poorly integrating a payment method, or integrating a payment method that's not a good fit for Bisq's trading protocol, can be costly mistakes for Bisq's users and dispute resolution mechanisms.

As a result, we request that you add responses to the following questions so that we can better consider your suggestion.

Please answer to the best of your ability. The more thorough you can be, the more you'll help us out, and the quicker your suggestion can be evaluated and implemented.

Why

It became the primary method for funds transfer between individuals when they don't share an institution for their financial accounts. Card to card payments are more costly and less flexible; same bank payments are on par, but quickly bumps into scenarios when both parties do not share a financial institution. Individuals-facing banks respond to the expectation of providing this method, and on average client systems encourage usage of this method after same bank. \ Bottom line: individuals prefer this method for p2p txs, especially over national bank transfer, for speed, cost, and convenience.

Region

In which areas of the world can this payment method be used? Mostly Russian Federation (RF). \ Won't be a big surprise if satellites/partners are supported too, see CBRF and NSPK coverage. Though it's impact would be significantly less there. (Actually they say there's transfers available (Cuba, Turkey ?), but it's pilot so very bank-dependent coverage and rules are subject to change for international txs.)

Currencies

RUB (aka RUR)

Chargeback risk

It's explicitly stated that there is no chargeback for p2p transfers in the system. (P2p transfers are done to phone number; payments to entities are done by QR-code and they're out of scope of this page.)

Getting money back require explicit consent from the receiver; each bank is responsible for establishing a procedure to own customers via which they can state an erroneous tx to get the info of the receiver / communicate their problem through the system / initiate a case / whatever else...

Size of user base

Conservative estimate from the top of my head would be 50 mil. individuals. They say over 70 mil. individuals. \ Most of bank account holders do have it; so you can take number of people in RF subtract those who aren't active financially, then subtract those who have strong enough issue against the method itself.

Data requirements

cellphone number, processing bank (could be default or a name; for processing with default one should be set in that bank system by recipient before the transfer is sent, for processing with a named bank recipient must have this cellphone num attached to an account in the named bank)

note that receiver will see enriched info (depending on their bank system), consisting of first name, patronymic, last name initial letter, cellphone num, txid

Verification

Bank provides receipts via their system. So it can be screen-shoot, run through TLSNotary, or taken as a paper from a front office. (Again very much like national bank transfer) Some banks could provide more data in the receipt than other.

Duration

The thing is instant in practice. 18h for upper bound seems balanced and safe estimation to me.

TODO Research if there were processing incidents and what are guarantees and practice time of processing recovery.

Also it can depend on receiving bank processing/issues. (Imagine that whole system is working, but one bank is struggling; then the tx will reach the bank instantly, but can take time on discretion of that bank to reach the account inside the bank.) I guess NSPK conducts testing when a bank joins the system, since generally the method is instant; still singular bank failures/issues can be expected.

Fees

https://www.cbr.ru/eng/psystem/sfp/#DropDown4_content

Fraud risk

There's no widely known problems based on this method.

Central bank supervision and regulation of the system makes it hard to a straight-forward fraud. (Again, similar to national bank transfer.) Usual fraud which doesn't rely on the payment method itself is still present, of course.

Also it could make sense to warn buyers that they shouldn't agree for QR-code during the trade, as that's very separate part of the system with different rules.

Payment amounts

Bank-depending respecting two general rules below.

https://www.cbr.ru/eng/psystem/sfp/#DropDown4_content says "Banks cannot set daily transfer limits lower than 150,000 rubles." So it can represent daily limit at some of the banks, other can provide much higher limits, and those even can be customer/tariff/plan tailored. There's 1 mil. RUB at once legal limit mentioned at Russian page of NSPK (seems like that applicable to national transfer as well); also they still accent that all other limits are bank-depending.

No minimum was found. (Note that 0,01 is the smallest denomination of RUB; and generally it's not relevant.)

Payment description

Generally offered, though it's bank-dependent. Seems that national bank transfer rules (and reasoning behind them) could be applied here. (Current rule is to leave blank or put either " " or "-" when impossible. Some banks fill the empty narrative with their template e.g. monetary assets transfer.)

skaunov commented 5 months ago

Naming of the method is minor problem itself. There's already "Faster payments" from other places; it's good to avoid confusions. I should note that I feel like those methods highly impacted the naming CBRF + NSPK gave to this. On the other hand RF is fond of abbreviations, so everybody knows the thing as СБП (SBP). I imagine in Bisq user would be expecting Latin transcript, also it would be strange/confusing globally to use Cyrillic in the name. As nobody use "FSP" for it and most users first try would be "SBP" that makes sense to put in the very beginning of the name. Then provide additional explanation to explain the thing and dispel any confusion.

skaunov commented 5 months ago

no chargeback (and requirement of consent) link for reference (in Russian) https://journal.tinkoff.ru/guide/sbp/#eight

pazza83 commented 5 months ago

Hi @skaunov

Thanks for proposing this.

With regards to time window. I think going for 24 hours would be best as this is the same used for other 'instant' payment methods.

With regards data requirements is any account info needed? You mention cell number but what is a BTC seller is registered for 2 banks with the same cell number. Would account info be needed?

skaunov commented 5 months ago

Seems like an ok number too - looks roughly the same to me. That's suppose 48h for the trade, right?

With regards to time window. I think going for 24 hours would be best as this is the same used for other 'instant' payment methods.

There's bank name mentioned after cell-number, and a note on default. So. Bisq should have like a checkbox for default which would deactivate input field for bank name. If that's chosen but the default isn't set, then it should be qualified as trade account data mishandling by the seller as it would hinder buyer experience: effectively he would not know what to do either guessing the bank, or asking and waiting input from the counter party. In the happy case of correct settings default brings flexibility to the seller: he is free to choose it, seller just hit the first choice while sending (it must be the default when set). If the default isn't set or seller wants to receive into a specific bank then he clears default checkbox in Bisq and input bank name of their choice; sender must chose that bank when sending. If sender has no account in that bank sending will not work - it's similar case to choosing default an notsetting/unsetting it. (Without set default the tx will go through if the first choice happen to have account for this number, when there's no account sending is just not possible.)

With regards data requirements is any account info needed? You mention cell number but what is a BTC seller is registered for 2 banks with the same cell number. Would account info be needed?

pazza83 commented 5 months ago

Seems like an ok number too - looks roughly the same to me. That's suppose 48h for the trade, right?

No it would be 24 hour trade window to complete the trade

sender must chose that bank when sending

How many banks are there to choose from? Could a list be created for the user to select from or is it best for the buyer to manually type their bank name into a field?

skaunov commented 5 months ago

Slightly over 200. I thought about it... I believe that input field is better.

Why do you talk about buyer, btw? IIRC the question asked the info for payment receiving, so it's the seller types-in their bank (or select default option instead) and buyer must choose it when sending.

On Wed, Jan 17 2024 at 03:53:27 PM -0800, pazza @.***> wrote:

...

How many banks are there to choose from? Could a list be created for the user to select from or is it best for the buyer to manually type their bank name into a field?

— Reply to this email directly, view it on GitHub https://github.com/bisq-network/growth/issues/288#issuecomment-1897508449, or unsubscribe <>. You are receiving this because you were mentioned.Message ID: @.>

skaunov commented 5 months ago

Below the line is draft of the requirements assessment table.


Essential Desirable Definite No’s
Very low risk of chargeback No risk of chargeback < very low risk of chargeback
Way to verify the sender in the received payment Way to verify the sender in the received payment and ability to enter a reference No way to verify the sender in the received payment
Trade time less than one week Instant payment Trade time more than one week
Singular Fiat currency Multi-currency Not a payment method for fiat currency
Significant user base Large user base No significant user base
High usability High usability and great user experience < high amount usability
No KYC required for sending and receiving payments No KYC required for sending and receiving payments, allows users to trade with upmost privacy. Minimal identifying information as possible (no names, email, phone etc required) Some KYC required (proof of address, ID, selfie) for sending and receiving payments
Low risk of scam attempts Very low risk of scam attempts < low risk of scam attempts
Traders can provide evidence of payment / receipt Traders can provide evidence of payment / receipt and Verification of payment can be made using PageSigner or similar Traders will be unable to provide evidence of payment / receipt
Minimum limit at least equal to at least account limits protocols No minimum limits Minimum limit not able to achieve account limits protocols
Maximum limits equal to at least 0.01 BTC Large payment limits up to 2 BTC Maximum limit is less than 0.01 BTC
Likely to increase liquidity Likely to increase liquidity and open markets for different countries and currencies Likely to decrease liquidity
Low risk of mediation Very low risk of mediation < low risk of mediation
Low risk for traders from government agencies No risk for traders from government agencies < low risk for traders from government agencies
Fees should not be a barrier to trading No fees for transactions Fees will be a barrier to trading
Only minor changes needed to trade protocol No changes needed to trade protocol > Minor changes needed to trade protocol
skaunov commented 5 months ago

for reference (in Russian) a non-primary sources says single tx is limited to 1 mil. RUB (1000000.00) https://journal.sovcombank.ru/sberezheniya/limiti-perevodov-po-sbp-skolko-mozhno-perevodit-v-sutki-i-za-mesyats#h_20999955431674805157570

pazza83 commented 5 months ago

Slightly over 200. I thought about it... I believe that input field is better.

Agreed.

Why do you talk about buyer, btw? IIRC the question asked the info for payment receiving, so it's the seller types-in their bank (or select default option instead) and buyer must choose it when sending.

Just thinking from the point of view when the BTC is on their bank app / website and needs to make the payment.

skaunov commented 5 months ago

when the BTC is on their bank app / website

"buyer"? I hope it's a typo; thought BTC in the bank app won't be that bad

pazza83 commented 5 months ago

Hi @skaunov

  1. Please can you confirm what fields you require in the GUI?
  2. Is there another payment methods with similar input fields?
  3. What should the payment method be referred to in the drop down list?
  4. Should there be any special information provided to users when creating the payment account?
  5. Should there be any special information about when payments (BTC Buyers)?
  6. Should there be any special information about when receiving payments (BTC Sellers)?
  7. Will there be a wiki about this payment method created?
skaunov commented 5 months ago

fields you require in the GUI?

four items

Required for sending process

Cellphone num

Would be nice if a warning be showed when

It's hard to say if those cases are really impossible, but they indicate probable mistake.

Bank name (for sending process)

Checkbox for default option (the first choice when sending). When unset one-line input is active.

Input would be nice to limit to Latin and Cyrillic characters. Length is quite speculative, 120 places should be enough.

Required for sending/receiving verification

Some (popular) banks doesn't indicate cellphone number after sending.

First name

Cyrillic/Latin one-line input, no line breaks, only letters, white-space and hyphen (for double surnames like "Апполон-Апостольский" and "de Gaulle"). If Bisq has international passport name type it would be appropriate for Latin. Would be nice to prohibit mixing Latin and Cyrillic. I remember rejection of numbers in individual legal name in RF, so it's safe to prohibit it for Cyrillic.

Initial letter of last name

Single uppercase Cyrillic/Latin character. Okay to be uppercased on/by input. Would be nice to restrict to Latin or Cyrillic as used in First name (i.e. to prohibit cross input fields mixing Latin and Cyrillic).

How similar do we seek? Amazon eGift card takes only cellphone no. ...

@pazza83

Is there another payment methods with similar input fields?

What should the payment method be referred to in the drop down list?

"SBP Faster payments CBRF (RUS)" Find the rationale why it's best to put it that way for clarity and search.

I need some examples on answering following set of questions.

Nothing special comes to my mind yet on its own. @pazza83

Should there be any special information provided to users when creating the payment account? Should there be any special information about when payments (BTC Buyers)? Should there be any special information about when receiving payments (BTC Sellers)?

Will there be a wiki about this payment method created?

I would adapt http://bisq.wiki/Faster_Payments and Strike (or other fresh/recommended example) pages to this one.

pazza83 commented 5 months ago

Hi @skaunov

Thanks for all the answers that is very useful.

Please can you explain a little more about:

Checkbox for default option (the first choice when sending). When unset one-line input is active.

Also regards the name ""SBP Faster payments CBRF (RUS)" I think "SBP Faster payments CBRF (RUB)" as using the currency code is more in-keeping with other payment methods. What are your thoughts?

skaunov commented 5 months ago

Let me try... questions would be helpful to direct the explaining, btw. :sweat_smile: First, maybe I should start expanding the way I formulated that one; so default -- instructs buyer to use account designated as such in their bank interface or use the choice that is presented as first/top one in the list there. Second, choosing default is an option in Bisq interface presented by a checkbox. @pazza83

P.s. It's a good angle with "RUB" let me take some time to thoroughly assess this way. Anyway this is a minor thing: both are good.

pazza83 commented 5 months ago

First, maybe I should start expanding the way I formulated that one; so default -- instructs buyer to use account designated as such in their bank interface or use the choice that is presented as first/top one in the list there. Second, choosing default is an option in Bisq interface presented by a checkbox.

Ok thanks. I am struggling to picture how it will look in the UI.

Can we not just give the buyer the option only to input one bank name. If they would like to add a second one they can add another SBP Faster Payment account on Bisq.

Same was that a user that wants to use multiple SEPA accounts need to add each one as a separate payment account in Bisq

skaunov commented 5 months ago

(After I added the comment I noticed one more source of confusion. I tend to use "add" default when speaking of Bisq, and I tend to use "set" default when speaking about SBP system itself. The difference is first is about having filed in Bisq account "default" and enjoying receiving money to anything you set outside of Bisq; while the second allows setting no designated bank as default at all.)

@pazza83 It kinda both...

If one wants to use multiple accounts he adds each one in Bisq as they're immutable. Think of default as just one more of those accounts one needs to add to use. Since it's a very valid when you want to have in Bisq the default and couple of specific accounts.

Regarding interface: Bisq input is used when adding the account. It's the moment when you click default or input the bank name. Then this info is displayed to the buyer. It doesn't provide any choice it only instructs buyer to one specific option: send to the named bank or to the one indicated as default.

(That "first list option" thing is due to the fact sometimes they have sending UI deliberately confusing to user and he can't say if default isn't set or displayed as the first in the sending list. In this case he should just use that first one option. Basically it would fail only if seller has no attached accounts at all which is clearly his violation of Bisq trade.)

Regarding UI maybe it would be helpful to think about the checkbox as "not default" which would activate input for specific bank name which buyer should select when sending money. When it's clear that way it's possible to drop the "not" word which just reverses checkbox state when it activates input field. After I read this I see that "brilliant" idea of explaining was likely glossy failed by me. :cry: At least it's something to reason about! I'm sorry I express the thing more complex than it is; that's my issue. :shrug:

pazza83 commented 3 months ago

Hi @skaunov

So I can understand please can you lay out the orders of the proposed payment account UI

  1. Account name holder
  2. Bank account details
  3. etc

Thanks

skaunov commented 3 months ago

I think it would be ok to spell out what is needed in a new comment at the bottom of the issue

I started to do this, and found myself repeating "fields you require in the GUI?". Could you indicate what in that section need elaboration for moving forward with the method. X)

GUI shows four items to the user for input on this method. All are mandatory.

Cellphone num

Would be nice if a warning be showed when

It's hard to say if those cases are really impossible, but they indicate probable mistake.

Would be also nice if a hint would be shown "+7..." to help people, as many used to domestic format ("8...") and such kind of hint is widespread.

Bank name

Consists of a checkbox and an input field. Checkbox controls if the input field is active. Flag disables input. Initial state is flagged.

Checkbox label is "default". If it's the case buyer should choose the financial institution designated as such in their sending UI (or first one if it has no such indication). Seller should accept tx from any financial institution.

If "default" is unchecked the input field is mandatory (so it makes sense to check if there's at least one letter before saving). Would be nice to limit to Latin and Cyrillic characters. Length is quite speculative, 120 places should be enough.

name

All the items should be together either Cyrillic, either Latin. (It would be nice to capitalize all the letters/inputs as it's done frequently. Some people don't like it. Smart way would be make an input all caps if a cap letter is found in the middle of a word or no caps found at all.)

I remember rejection of numbers in individual legal name in RF, so it's safe to prohibit it for Cyrillic.

first name

One-line input, no line breaks, only letters, white-space and hyphen (for double surnames like "Апполон-Апостольский" and "de Gaulle"). If Bisq has international passport name type it would be appropriate for Latin.

patronymic

Same rules as the first, but can be empty.

When left empty a warning should appear that it would be treated as its absence in full legal name and counter-party can account its presence in the statement/receipt as name mismatch.

(Context. Patronymics sometimes are omitted, especially when registering in the Internet. Though they're never omitted in banking. Tiny portion of citizens/users have no patronymic in their legal name.)

Initial letter of the last name

Single uppercase character. Okay to be uppercased on/by input.

pazza83 commented 3 months ago

Hi @skaunov

Thanks for providing all the information.

@jmacxx do you have all the info you need to add this is a payment method?

skaunov commented 3 months ago

Also it makes sense to put it as a first RUB account choice when creating a new one, since it will be a "go to" method.