bisq-network
SBP Faster payments CBRF (RUB)
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.)
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.
no chargeback (and requirement of consent) link for reference (in Russian) https://journal.tinkoff.ru/guide/sbp/#eight
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?
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?
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?
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: @.>
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~~ |
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
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.
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
Hi @skaunov
- Please can you confirm what fields you require in the GUI?
- Is there another payment methods with similar input fields?
- What should the payment method be referred to in the drop down list?
- 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?
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.
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?
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.
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
(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:
Hi @skaunov
So I can understand please can you lay out the orders of the proposed payment account UI
- Account name holder
- Bank account details
- etc
Thanks
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.
Hi @skaunov
Thanks for providing all the information.
@jmacxx do you have all the info you need to add this is a payment method?
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.
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).
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: @.***>
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?
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?
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.)
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.
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.
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.
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)?
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.