SBP Faster payments CBRF (RUB)

[skaunov]

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

• up to 100,000 rubles a month can be transferred free of charge;
• if money transfers exceed 100,000 rubles a month, a bank fee may not be over 0.5% of the transfer amount and over 1,500 rubles per transaction.

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]

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]

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

[pazza83]

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]

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]

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]

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

• basically all sending system provide filtering on type
• it's hard for us to track and add/remove institutions on Bisq side
• localization issues: we kinda will need to have both lists with Russian and Latin names (or an ugly single list containing both hence same complexity in tracking)
• people are incentivized to provide and keep facilitating naming in their account, on the other hand tracking of all legal names according to renaming happening isn't fun (the point is that seller knows how to indicate their bank so that buyer wouldn't be confused, but for us the best choice is always correct legal name)
• tail of small unpopular banks will never be used in trades or hit it once or twice - adding and tracking them will be waste of resources

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]

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]

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]

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]

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]

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]

fields you require in the GUI?

four items

Required for sending process

Cellphone num

Would be nice if a warning be showed when

• there's letters in it or "#",
• it has less than 10 digits,
• prefix isn't "+7" or "007".

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]

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]

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]

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]

(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]

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]

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

• there's letters in it or "#",
• it has less than 10 digits,
• prefix isn't "+7" or "007".

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]

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]

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.

[cparke2]

Any update on adding this SBP payment method? It doesn't seem like there was any missing information here about it and everything was ready for it to be added. Are we just waiting for a developer to do it?

I'm asking because I did one of these ruble trades as BTC buyer recently using the "National Bank Transfer" payment method, since that's the closest thing we have to use right now. Seller's bank information was wrong on the payment account (no BIK code and the account number was not 20 digits), so I had to ask for the phone number in the trade chat to send rubles by SBP instead. That is really awkward in the event of a dispute. He confirmed receiving the payment and everything was fine, but I'd really rather there was a "Faster Payments System (SBP) (RUSSIA)" payment account in Bisq with the seller's listed phone number and indicated target bank name on the trade itself. (the SBP service lists every bank that the BTC seller has a bank account opened at, with a default bank pre-selected).

[skaunov]

You can add wireframes to this to facilitate! I was asked for that when the issue hit an appropriate developer, and when I had capacity to do them there was no understanding for developers availability due to uncertainty from new legal cases on other projects. And last time I asked I got no reply at all.

On Sun, Sep 15 2024 at 07:17:47 PM -0700, cparke2 @.***> wrote:

Any update on adding the SBP payment method? It doesn't seem like there was any missing information here about it and everything was ready for it to be added.

I'm asking because I did one of these ruble trades as BTC buyer recently using the "National Bank Transfer" payment method, since that's the closest thing we have to use right now. Seller's bank information was wrong on the payment account (no BIK code and the account number was not 20 digits), so I had to ask for the phone number in the trade chat to send rubles by SBP instead. That is really awkward in the event of a dispute. He confirmed receiving the payment and everything was fine, but I'd really rather there was a "Faster Payments System (SBP) (RUSSIA)" payment account in Bisq with the seller's listed phone number and indicated target bank name on the trade itself. (the SBP service lists every bank that the BTC seller has a bank account opened at, with a default bank pre-selected).

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

[cparke2]

I'm not sure what you mean by "wireframes"? Is it a diagram or screen mock-up or something?

If I were adding this payment method, the screen would have these fields:

Payment Method: SBP (Russia)
Account owner full name: _____________
Mobile Number: +7 (###) ###-##-## [10-digit phone number with fixed country code prefix of +7]
Bank Name: _________________
Currency: Russian Ruble
Max. trade duration: 1 day
No account signing feature for this payment method.

So I'm taking your reply to mean that everything is good with adding this payment method, just somebody needs to do it?

[skaunov]

mock-up

I'm not sure what you mean by "wireframes"? Is it a diagram or screen mock-up or something?

"+7" is too restrictive I guess, btw; is there any restriction on registering numbers from other networks? full name feels too invasive, ain't that first + patronymic + initial letter of family

If I were adding this payment method, the screen would have these fields:

Payment Method: SBP (Russia)
Account owner full name: _____________
Mobile Number: +7 (###) ###-##-## [10-digit phone number with fixed country code prefix of +7]
Bank Name: _________________
Currency: Russian Ruble
Max. trade duration: 1 day
No account signing feature for this payment method.

yes

So I'm taking your reply to mean that everything is good with adding this payment method, just somebody needs to do it?

[cparke2]

At present, only +7 phone numbers can be entered into the bank's form for ordering a SBP payment. The bank system I use (Uralsib) automatically displays the +7 when I enter the first digit of the phone number, and I cannot override that by trying to enter something like +1 first instead. The reason why, I think, is the phone number registered for use with SBP to receive payments is linked directly to the bank account holder's Russian interior passport and interior residence registration through the mobile phone federal registration. The phone number can be only 10 digits (Russian carriers only), prefixes like +7 or 8 are informational only and not part of the SBP database. For Bisq purposes, we do not need to show the +7, just require a 10-digit phone number.

It's true that the SBP system only shows the first initial of the family name (last name) to help identify that the phone number you entered is for the right person. That's how it appears on the bank's transaction receipt for the recipient's name as well. However, pretty much every payment method on Bisq asks for the full account owner's name, as is the case with other P2P platforms that I've used. This SBP policy is an oddity and could change in the future, idk (when I first used the system, I though it was the first name's initial, not the last name's, and was confused and worried that payment was the going to be sent to the wrong person). Users certainly don't have to provide their full last name on the Bisq account information for any payment method, so I say leave it up to the user to decide what to enter for their name (maybe an initial pop-up can explain that they have an option to provide only last name initial). In the event of a dispute, I doubt a mediator would deny that the full last name entered into the Bisq account does not match a bank payment receipt that only shows the last name initial, but maybe @pazza83 could chime in on this subject? (ex: SBP payment was sent to: Oleg Borisovich E.)

[skaunov]

I'm just not a huge expert in the system, and was defining the method to not restrict things I couldn't grasp in reasonable time. Like if that restricted to RF cell providers or "+7" code (like would it take a RK number?), if a foreign citizen can join the system (they can have bank accounts at least), if customer proves only control over the tel number and not it's ownership when joining (why send the code then if they could match account and tel number owner).

The policy is not an oddity but a smart approach. Full name with tel number is quite a combination; and taking last name out is an improvement. I couldn't find a requirement to own the tel number only prove the messaged code when visiting a branch.

I guess Bisq method should be minimal in collected info; so with altcoins all user provide is their address. I mean why would we ask anything more then payment provider needs.

[cparke2]

It doesn't seem possible to me for someone without a Russian mobile number can use SBP. That's just the way this payment system is designed; you can't enter a non-Russian phone number to locate the recipient. You can't get a one-time code using a landline Russian number as far as I know, so how would the bank verify it for use in receiving SBP payments? (I suppose if the bank has a voice code delivery system that could work) SBP also specifically does not support sending payments abroad, as there's other payment networks like "Unistream" for that.

The account owner full name is provided as a safety to help verify that the phone number was entered correctly and recipient is the right person before sending out the payment. It also is typically the only official way that the BTC seller (payment recipient) can match and identify payments received with individual buyers and a particular trade (recall that we are generally not supposed to use payment message fields to identify the trade). Furthermore, I find that most payment methods on Bisq collect the account owner's full name, even if the buyer or seller technically shouldn't need it. Ultimately, every peer has to decide for themselves how much account information they want to share with their trade partners. So I think this issue is getting off-topic and should stop until @pazza83 returns, as the same argument that you're asserting here to limit the account owner's full name on a new payment method could similarly be applied to other existing Bisq payment methods too.

[skaunov]

You persuaded me with the first evidence for Russian area code; I just mentioned some other presuppositions which needs evidence before restricting. I agree that main point is getting the thing done, and details kind of wanders the discussion away. :handshake: (When I was defining the method above, my idea was that RB infrastructure could be included, bringing one more area code; speaking of rules changes.)

Could you also indicate any examples of most Bisq payment methods collects the account owner's full name, even when it's not required for the trade completion? I guess that @pazza83 would like to have a look at excessive information too.

[cparke2]

Alright, I looked at some payment methods like "Cash by Mail" and there is support there for a pseudo-name (nym) rather than a full name.

In Russian mode, I think the payment method probably should display as "Система быстрых платежей (СБП) (Россия)". In English mode, "Faster Payments System (SBP) (Russia)". Look right?

What do you propose the account owner name field on this new payment method should prompt for (in Russian and in English)?

[skaunov]

For English the current name was inferred, I feel it's still a bit better. https://github.com/bisq-network/growth/issues/288#issuecomment-1910858369 In Russian I have no opinion, tbh.

Last name initial letter, first name and patronymic (if present). And the same for Russian.

[cparke2]

What does "CBRF" mean? Central Bank Russian Federation? Seems unnecessary, 3 acronyms in payment method name seems overkill. I'm not sure we have any other payment methods that are listed with the acronym first?

I really would like a native Russian speaker to specify how to prompt in Russian for first name, middle names (patronymic for many people who will be using this payment method), and last name initial. Also, on my SBP bank receipts, the receiver's name is not in the usual last name, first name, middle name format, but rather first name, middle name, last name initial.

[skaunov]

Usually I would say the same, but here it's for a purpose. To fast and reliable find the method in the long list. CBRF is the owner of the system to distinct it from other faster payments; also RUB is capitalization, not an acronym; and having just two when RF is notoriously fond of them is like an achievement.

What does "CBRF" mean? Three acronyms in payment method name seems overkill. I'm not sure we have any other payment methods that are listed with the acronym first?

Receipts differ widely IIRC, seems to be financial institution dependent. And AFAIK there two conventional approaches: the traditional name-(patronymic)-surname, and USSR-ish surname-name-(patronymic). (Or is the last one Germanic where comma have been lost? Never bothered to really get into that.) But both are widespread, since the latter is in favor of the state as well as mad acronyms. :smile: The thing is I never switched the system to Russian. Would "Имя, отчество, первая буква фамилии." fit? I feel like it's a minor stuff, tbh.

I really would like a native Russian speaker to specify how to prompt in Russian for first name, middle names (patronymic for many people who will be using this payment method), and last name initial. Also, on my SBP bank receipts, the receiver's name is not in the usual last name, first name, middle name format, but rather first name, middle name, last name initial.

[cparke2]

Yes, I'm trying to prevent a fondness for acronyms from polluting the application. CBRF is too much, SBP is really all that people need to see to recognize this payment method.

I looked at application in Russian today, and the payment methods most applicable to Russians are translated into Russian, but they also sort to the bottom of the list! That's a separate issue, but perhaps they belong above the untranslated payment methods? (if that can be done uniformly for all languages)

So I need to figure out how to locally build the Bisq application, then I'll try to add this new payment method as we've discussed and revert here. Not sure yet how to share dev builds with non-devs for user testing and submit test evidence with code changes, but I'm sure there's a formal process described somewhere in the dev docs...

[skaunov]

That's a noble intention. I kind of been there, and got the fact it's actually a useful label to mark a state actor; this dialect implicitly and effectively shows to a person that they will be interacting with state and should be prepared for that.

"SBP" isn't that recognizable in Latin, and there's also few faster payments present.

I fell that if account creation would first ask for currency and then offer relevant methods it would swipe the problems you mention.

Best of luck with adding the method!

[cparke2]

That's a noble intention. I kind of been there, and got the fact it's actually a useful label to mark a state actor; this dialect implicitly and effectively shows to a person that they will be interacting with state and should be prepared for that.

That's a very negative outlook. You forget that I need this payment method added because I actually need to use it.

I was able to build Bisq from source yesterday, and I went pretty far ahead with adding "Faster Payments System (SBP)" underneath the UK's "Faster Payments" account type. We could adjust the name of the UK payment method in the list, but really I don't know if it's that important, since both account types only support one currency. It is possible to show a pop-up informational dialog when you begin adding either account type too, if special mentions are appropriate. Also, Bisq source code provides for a, "country-based payment account" too, but I don't entirely understand what it does yet besides add a "country" selection box. Try adding the "MercadoPago" payment method in your Bisq application, and you can see both options in action.

At present, I have a build error with Bisq following my changes. It involves something called the, "Protocol Buffer" code generator, so I am seeking out some kind of help from the dev board to figure out how to get that to recognize the new payment method's payload. For testing, Bisq has a Makefile that sets up a fake Bitcoin node and fake Bisq seed node and two fake users that can trade with each other through these, so dev testing seems pretty straightforward.

Please just be a little more patient, and if you have any thoughts on the above comments, please let me know.

[skaunov]

I have no idea why you say this, though nvm. (I mean I didn't get neither the point, nor a reason.)

That's a very negative outlook. You forget that I need this payment method added because I actually need to use it.

I'd guess that's the contrary: looks like Mercado system has country branching and user might need to choose in which segment their account exists.

Take your time! At least merging seems to be quick!

[cparke2]

So I got the compile fixed, and worked through some other issues to get the new payment method to appear in the payment methods list and work for creating, exporting, and importing accounts.

Below is what the new screens look like in the application (in Russian):

And her they are again in English, where we are a bit more concerned about confusions with the UK "Faster Payments" payment method:

Please check the translation that I got from Google Translate, sometimes it produces weird text.

I also just submitted a pull request to fix the sorting of the payment methods, so that when running in a non-English language mode, the payment methods that have been translated will appear on the top of the list rather than on the bottom as it has been. That may not help the Western Europe languages (Spanish, French, etc.) that also use the Latin alphabet characters, but at least in their case, the translated entries are already sorted together with the English ones and they are not all on the bottom.

Next steps are to finish the translations related to the new payment method (I'm not translating anything else, that language file is very incomplete, somebody else needs to volunteer to run that file through Google Translate and then review the output).

Also, this weekend I will try to setup the test environment to do a sample trade with my isolated, local node using the new payment method. Plus I have to add the new text to all the language files, and finally write unittests on the new modules, then submit the code for merge.

Anybody know when the next release of Bisq1 is planned for?

[skaunov]

Link the language files, pls. I hope to create a wiki page for the method to accompany your progress.

[cparke2]

The Language files are on GitHub here:

Language files directory

The way the application is designed, every string must be defined in every language, or there will be a runtime exception, so there's a ton of English in the _ru file and all the rest of them, really.

[skaunov]

thanks! I meant mostly those you pictured, seems like you didn't commit that yet

[cparke2]

Yes, I need to commit changes to all the language files because I added new strings. That's a bit tedious since there's like 20 languages involved.

[cparke2]

The only other string I added, besides what you've seen above is this one sent out upon security deposits being confirmed into the multisig:

portfolio.pending.step2_buyer.sbp=Please pay {0} via your bank's SBP "Pay by Telephone Number" service using the seller's information on the next screen.\n\n

[skaunov]

I just want to type a little bit less. =))

@pazza83 , how do I submit the wiki page? Do you want to create an account for me, or should I just attach that as a file?

[cparke2]

Yes, I'll post the long string definition for that dialog box. Beware, we do want the English and Russian to approximately match, so if you're doing more than grammar and vocabulary, we probably should change the English accordingly.

[cparke2]

Hi Sergey,

These are the display strings in the Russian language file that I added to create the new SBP payment method (last one I didn't even try yet to translate):

payment.sbp.info.account=Система быстрых платежей (СБП) — это межбанковский сервис денежных переводов в РОССИИ, позволяющий физическим лицам \
 совершать личные платежи, используя только номер мобильного телефона.\n\n\
 1. Сервис предназначен для платежей и переводов между российскими банковскими счетами только в российских рублях.\n\n\
 2. Для использования сервиса можно зарегистрировать только номера мобильных операторов России (+7 код страны).\n\n\
 3. Вам необходимо создать отдельную учетную запись Bisq для каждого банка, в котором у вас есть счет и вы хотите получать средства.\n\n\
 4. СБП отображает имя, отчество и первую букву фамилии получателя для проверки правильности номера телефона. \
  Поэтому вам следует ввести имя владельца учетной записи в учетной записи Bisq, используя тот же стиль.

payment.account.owner.sbp=Имя владельца счёта (Имя, отчество, первая буква фамилии)

validation.phone.incorrectLength=Поле должно содержать {0} символов

portfolio.pending.step2_buyer.sbp=Please pay {0} via your bank's SBP "Pay by Telephone Number" service using the seller's information on the next screen.\n\n

However, the below pre-existing strings are untranslated in the file, which probably makes it really difficult for some people to use this application with confidence. If you have any time to do some extra translations, I really feel these are needed for the application to be effectively useful in this language..

payment.maxPeriodAndLimit=Max. trade duration: {0} / Max. buy: {1} / Max. sell: {2} / Account age: {3}

mainView.menu.buy=Buy

mainView.menu.sell=Sell

mainView.footer.p2pInfo=Bitcoin network peers: {0} / Bisq network peers: {1}

mainView.footer.btcInfo.synchronizingWith=Synchronizing with {0} at block: {1} / {2}

mainView.footer.btcInfo.synchronizedWith=Synced with {0} at block {1}

mainView.footer.usingTor=(via Tor)

mainView.footer.btcFeeRate=/ Fee rate: {0} sat/vB

mainView.footer.btcInfo.connectionFailed=Connection failed to

offerbook.availableOffersToBuy=Buy {0} with {1}

offerbook.availableOffersToSell=Sell {0} for {1}

offerbook.filterByCurrency=Choose currency

offerbook.filterByPaymentMethod=Choose payment method

offerbook.matchingOffers=Offers matching my accounts

offerbook.cloneOffer=Clone offer (with shared maker fee)

offerbook.clonedOffer.tooltip=This is a cloned offer with shared maker fee transaction ID.\n\Maker fee transaction ID: {0}

offerbook.nonClonedOffer.tooltip=Regular offer without shared maker fee transaction ID.\n\Maker fee transaction ID: {0}

offerbook.cannotActivate.warning=This cloned offer with shared maker fee cannot be activated because it uses the same payment method and currency as another active offer.\n\nYou need to edit the offer and change the payment method or currency or deactivate the offer which has the same payment method and currency.

offerbook.cannotActivateEditedOffer.warning=You can't activate an offer that is currently edited.

offerbook.clonedOffer.info=By cloning an offer one creates a copy of the given offer with a new offer ID but using the same maker fee transaction ID.\n\nThis means there is no extra maker fee needed to get paid and the funds reserved for that offer can be re-used by the cloned offers. This reduces the liquidity requirements for market makers and allows them to post the same offer in different markets or with different payment methods.\n\nAs a consequence if one of the offers sharing the same maker fee transaction is taken all the other offers will get closed as well because the transaction output of that maker fee transaction is spent and would render the other offers invalid. \n\nThis feature requires to use the same trade amount and security deposit and is only permitted for offers with different payment methods or currencies.\n\nFor more information about cloning an offer see: [HYPERLINK:https://bisq.wiki/Cloning_an_offer]

portfolio.pending.step3_seller.buyersAccount=Buyers account data

portfolio.pending.step3_seller.releaseBitcoin=Release Bitcoin

portfolio.pending.step3_seller.showBsqWallet=Show payment in BSQ wallet

portfolio.pending.step3_seller.warn.part2=You still have not confirmed the receipt of the payment. Please check {0} if you have received the payment.

portfolio.pending.step3_seller.openForDispute=You have not confirmed the receipt of the payment!\nThe max. period for the trade has elapsed.\nPlease confirm or request assistance from the mediator.

support.tab.mediation.support=Mediation

support.tab.arbitration.support=Arbitration

support.backgroundInfo=Bisq is not a company, so it handles disputes differently.\n\nTraders can communicate within the application via secure chat on the open trades screen to try solving disputes on their own. If that is not sufficient, a mediator can step in to help. The mediator will evaluate the situation and suggest a payout of trade funds. If both traders accept this suggestion, the payout transaction is completed and the trade is closed. If one or both traders do not agree to the mediator's suggested payout, they can request arbitration.The arbitrator will re-evaluate the situation and, if warranted, personally pay the trader back and request reimbursement for this payment from the Bisq DAO.

support.initialInfo=Please enter a description of your problem in the text field below. Add as much information as possible to speed up dispute resolution time.\n\nHere is a check list for information you should provide:\n\t● If you are the BTC buyer: Did you make the Fiat or Altcoin transfer? If so, did you click the 'payment started' button in the application?\n\t● If you are the BTC seller: Did you receive the Fiat or Altcoin payment? If so, did you click the 'payment received' button in the application?\n\t● Which version of Bisq are you using?\n\t● Which operating system are you using?\n\t● If you encountered an issue with failed transactions please consider switching to a new data directory.\n\t  Sometimes the data directory gets corrupted and leads to strange bugs. \n\t  See: https://bisq.wiki/Switching_to_a_new_data_directory\n\nPlease make yourself familiar with the basic rules for the dispute process:\n\t● You need to respond to the {0}''s requests within 2 days.\n\t● {1}\n\t● The maximum period for a dispute is 14 days.\n\t● You need to cooperate with the {2} and provide the information they request to make your case.\n\t● You accepted the rules outlined in the dispute document in the user agreement when you first started the application.\n\nYou can read more about the dispute process at: {3}

support.initialInfoRefundAgent=Please describe why have you opened arbitration, or why do you think your peer did so. Add as much information as possible to speed up dispute resolution time. Mediation and trading chats are not shared with the arbitrator.\n\nHere is a check list for information you should provide:\n\t● If you are the BTC buyer: Did you make the Fiat or Altcoin transfer? If so, did you click the 'payment started' button in the application? Did you accept mediator's suggestion?\n\t● If you are the BTC seller: Did you receive the Fiat or Altcoin payment? If so, did you click the 'payment received' button in the application? Did you accept mediator's suggestion?\nPlease make yourself familiar with the basic rules for the dispute process:\n\t● You need to respond to the {0}''s requests within 2 days.\n\t● {1}\n\t● The maximum period for a dispute is 14 days.\n\t● You need to cooperate with the {2} and provide the information they request to make your case.\n\t● You accepted the rules outlined in the dispute document in the user agreement when you first started the application.\n\nYou can read more about the dispute process at: {3}

support.initialMediatorMsg=Mediators will generally reply to you within 24 hours.\n\t  If you have not had a reply after 48 hours please feel free to reach out to your mediator on Matrix.\n\t  Mediators usernames on Matrix are the same as their usernames within the Bisq app.\n\t  Your mediator is: {0}

support.initialArbitratorMsg=Arbitrators will generally reply to you within 5 days.\n\t  If you have not had a reply after 7 days please feel free to reach out to your arbitrator on Matrix.\n\t  Arbitrators usernames on Matrix are the same as their usernames within the Bisq app.\n\t  Your arbitrator is: {0}

support.youOpenedDisputeForMediation=You requested mediation.\n\n{0}\n\nBisq version: {1}

support.peerOpenedTicket=Your trading peer has requested support due to technical problems.\n\n{0}\n\nBisq version: {1}

support.peerOpenedDispute=Your trading peer has requested a dispute.\n\n{0}\n\nBisq version: {1}

support.peerOpenedDisputeForMediation=Your trading peer has requested mediation.\n\n{0}\n\nBisq version: {1}

support.mediatorsDisputeSummary=System message: Mediator''s dispute summary:\n{0}

support.mediatorReceivedLogs=System message: Mediator has received logs: {0}

support.mediatorsAddress=Mediator''s node address: {0}

support.warning.disputesWithInvalidDonationAddress=The delayed payout transaction has used an invalid receiver address. It does not match any of the DAO parameter values for the valid donation addresses.\n\nThis might be a scam attempt. Please inform the developers about that incident and do not close that case before the situation is resolved!\n\nAddress used in the dispute: {0}\n\nAll DAO param donation addresses: {1}\n\nTrade ID: {2}{3}

support.warning.disputesWithInvalidDonationAddress.mediator=\n\nDo you still want to close the dispute?

support.warning.disputesWithInvalidDonationAddress.refundAgent=\n\nYou must not do the payout.

support.warning.traderCloseOwnDisputeWarning=Traders can only self-close their support tickets when the trade has been paid out.

support.warning.ticketNotAcknowledged=Ticket not acknowledged.

support.resendTicket=This trader has not acknowledged receipt of the dispute ticket.\nWould you like to re-send the ticket?

support.info.disputedTradeUpdate=Disputed trade update: {0}

account.menu.walletInfo=Wallet info

account.menu.walletInfo.balance.headLine=Wallet balances

account.menu.walletInfo.balance.info=This shows the internal wallet balance including unconfirmed transactions.\nFor BTC, the internal wallet balance shown below should match the sum of the 'Available' and 'Reserved' balances shown in the top right of this window.

account.menu.walletInfo.path.info=If you import seed words into another wallet (like Electrum), you'll need to define the path. This should only be done in emergency cases when you lose access to the Bisq wallet and data directory.\nKeep in mind that spending funds from a non-Bisq wallet can bungle the internal Bisq data structures associated with the wallet data, which can lead to failed trades.\n\nNEVER send BSQ from a non-Bisq wallet, as it will probably lead to an invalid BSQ transaction and losing your BSQ.\n\n

account.menu.walletInfo.openDetails=Show raw wallet details and private keys

settings.preferences.supportLanguageWarning=In case of a dispute, please note that mediation is handled in {0} and arbitration in {1}.

funds.withdrawal.txFee=Withdrawal transaction fee (satoshis/vbyte)

funds.withdrawal.useCustomFeeValueInfo=Insert a custom transaction fee value

funds.withdrawal.txFeeMin=Transaction fee must be at least {0} satoshis/vbyte

funds.withdrawal.txFeeTooLarge=Your input is above any reasonable value (>5000 satoshis/vbyte). Transaction fee is usually in the range of 50-400 satoshis/vbyte.

funds.reserved.reserved=Reserved in local wallet

funds.locked.locked=Locked in multisig

funds.tx.createOfferFee=Maker and tx fee

funds.tx.takeOfferFee=Taker and tx fee

funds.tx.multiSigDeposit=Multisig deposit

funds.tx.multiSigPayout=Multisig payout

funds.tx.disputePayout=Dispute payout

funds.tx.disputeLost=Lost dispute case

funds.tx.collateralForRefund=Refund collateral

funds.tx.timeLockedPayoutTx=Time locked payout tx

funds.tx.refund=Refund from arbitration

funds.tx.unknown=Unknown reason

funds.tx.memo=Memo

shared.txFee=Transaction Fee

shared.tradeFee=Trade Fee

shared.buyerSecurityDeposit=Buyer Deposit

shared.sellerSecurityDeposit=Seller Deposit

shared.question.useBisqWalletForFunding=Would you like to always use your Bisq wallet for funding?\n\nThe make/take offer process will take less steps by choosing this. However, funding from an external wallet could potentially be better for privacy.\n\n(This can be also be controlled in Settings: "Fund offer/trades from Bisq wallet").

shared.exportCSV=Export to CSV

shared.summary=Show summary

shared.sendFundsDetailsWithFee=Sending: {0}\nFrom address: {1}\nTo receiving address: {2}\nRequired mining fee is: {3} ({4} satoshis/vbyte)\nTransaction vsize: {5} vKb\n\nThe recipient will receive: {6}\n\nAre you sure you want to withdraw this amount?
# suppress inspection "TrailingSpacesInProperty"

shared.sendFundsDetailsDust=Bisq detected that this transaction would create a change output which is below the minimum dust threshold (and therefore not allowed by Bitcoin consensus rules). Instead, this dust ({0} satoshi{1}) will be added to the mining fee.\n\n\n

shared.copiedToClipboard=Copied to clipboard!

shared.accountNameAlreadyUsed=That account name is already used for another saved account.\nPlease choose another name.

shared.cannotDeleteAccount=You cannot delete that account because it is being used in an open offer (or in an open trade).

shared.refundAgentForSupportStaff=Refund agent

shared.delayedPayoutTxId=Delayed payout transaction ID

shared.delayedPayoutTxReceiverAddress=Delayed payout transaction sent to

shared.unconfirmedTransactionsLimitReached=You have too many unconfirmed transactions at the moment. Please try again later.

shared.numItemsLabel=Number of entries: {0}

shared.filter=Filter

shared.enabled=Enabled

shared.me=Me

dao.reputationBalance=Merit Value (not spendable)

popup.info.shutDownQuery=Are you sure you want to exit Bisq?

Note that Bisq currently now has over 3,000 display strings! This is just a small selection that I feel is most important to get translated.

[cparke2]

Good news! The pull request adding this new payment method has been approved and merged! That means it will become available to all users in the next release of the Bisq1 client application.

The only remaining issues, which are really a separate issue, are Russian translations of many important strings, as well as perhaps some adjustments to the pop-up description for the SBP payment method. Plus a new wiki page on the payment method.

Last call for @pazza83 to offer some comments and guidance!

[skaunov]

I adapted http://bisq.wiki/Faster_Payments to this one, and will also check the other page if something should be added. I'd really like to be editing this at , but until I'm just attaching the file.

@pazza83 , how do I submit the wiki page? Do you want to create an account for me, or should I just attach that as a file?

[ ] align name to the released (currently still adjusting in the PR) [ ] indicate the minimal version for it when we will have the number

[cparke2]

I've pinged @pazza83 several times on Matrix, but each time he views the response but provides no reply and does not appear here. Appreciate the effort Sergey, it looks good as a first draft, and sorry if it may be some time until the wiki gets updated with this information. In the meantime, my pop-up screen in the application will have to suffice.

For reference, there are some naming changes coming in follow-up discussions with the approver, @HenrikJannsen:

"Faster Payment System (UK)" https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/

"Faster Payments System-SBP (Russia)" https://www.cbr.ru/eng/psystem/sfp/

[pazza83]

Any update on adding this SBP payment method? It doesn't seem like there was any missing information here about it and everything was ready for it to be added. Are we just waiting for a developer to do it?

Just following up on this now.

The issue was on hold as the dev that I was working with the add the payment method left the project. That and the coming change from Bisq 1 to Bisq 2 meant that I have not really been giving much priority to adding new payment methods to Bisq 1.

It would be good to add more payment methods to Bisq, it is just that doing to now does require doing so twice, first on Bisq 1 and then again with Bisq 2.

Just wanted to give a little context to the above issue.

[pazza83]

I doubt a mediator would deny that the full last name entered into the Bisq account does not match a bank payment receipt that only shows the last name initial, but maybe @pazza83 could chime in on this subject? (ex: SBP payment was sent to: Oleg Borisovich E.)

Correct. From a mediation perspective the 'Account owner full name' field is used to make sure:

• Sender has sent funds to the correct person.
• The BTC Seller can identify the buyer's payment.
• Neither the buyer nor seller is using an account that is not in the trade contract.