SBP Faster payments CBRF (RUB) #288
Comments
|
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?
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.)
|
No it would be 24 hour trade window to complete the trade
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
<#288 (comment)>,
or unsubscribe
<***>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Below the line is draft of the requirements assessment table.
|
|
for reference (in Russian) |
Agreed.
Just thinking from the point of view when the BTC is on their bank app / website and needs to make the payment. |
"buyer"? I hope it's a typo; thought BTC in the bank app won't be that bad |
|
Hi @skaunov
|
fields you require in the GUI?four items Required for sending processCellphone numWould 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 verificationSome (popular) banks doesn't indicate cellphone number after sending. First nameCyrillic/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 nameSingle 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. ...
What should the payment method be referred to in the drop down list?"SBP Faster payments CBRF (RUS)" I need some examples on answering following set of questions.Nothing special comes to my mind yet on its own.
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:
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. 😅 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. |
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; @pazza83 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. |
skaunov
changed the title
|
Hi @skaunov So I can understand please can you lay out the orders of the proposed payment account UI
Thanks |
GUI shows four items to the user for input on this method. Cellphone numWould 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 nameConsists 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 "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. nameAll 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 nameOne-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. patronymicSame 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 nameSingle 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
<#288 (comment)>,
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: 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
"+7" is too restrictive I guess, btw; is there any restriction on registering numbers from other networks?
yes
|
|
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. 🤝 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. |
|
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. |
|
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:
|
|
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? |
|
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. |
|
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): 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.. 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. |
This is the standard P2P payment method in Russia to perform funds transfers and payments between Russian bank accounts in Russian Rubles. There is no chargeback risk. Recipient bank account is located using telephone number and bank name, and sender receives recipients first name, middle name, and initial of last name to confirm the phone number entered is correct before sending. Adding this new payment method has been discussed at length on the GitHub 'growth' channel at: bisq-network/growth#288
|
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! |
|
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 <bisq.wiki>, but until I'm just attaching the file.
[ ] align name to the released (currently still adjusting in the PR) |
|
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)" "Faster Payments System-SBP (Russia)" |
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. |
Correct. From a mediation perspective the 'Account owner full name' field is used to make sure:
|
There are a few examples:
Although trade completion might not require access to the Account owner full name' field it is useful for the reasons listed above. |
@cparke2 thanks for doing this. It looks great. For the information screen will the text be shown in Russian if someone has that set as their language?
That is a good idea. The payment methods do require some way of sorting them. Ideally by currency. As Bisq 1 will be retired soon I think the efforts for this are best sorting this out will be in Bisq 2. What you are doing sounds good though for a quick fix :)
Yes agreed the translations are missing for lots of the new payment methods. Again I would not worry too much about this. I think going for Russian first text for a Russian payment method is appropriate.
No, but once the PR is to be included I can find out for you. |
I have added it for you here: https://bisq.wiki/Faster_Payments_System_SBP I have also included a link to it here: https://bisq.wiki/Payment_methods |
Once added it would be great to get some offers up. I can see their are 2 offers for RUB now for 'national bank transfers' The best way letting to existing Bisq users know about it's addition is the addition of some offers. Thanks @cparke2 for making these additions. Thanks @skaunov for pushing forward with the changes. Apologies for my late replies |
Nice to see you back, hope you're doing well! How do I edit that? Just send a Matrix message with edits? (I already see a typo in the first line, and also wanted to link narrative field requirement instead of restating it.) |
Ok, thanks @pazza83 for reviewing the recent activity on this thread and your comments. As you may have surmised, this new Bisq1 payment method is now merged into 'master' and will be included in the next release. I am just working on some follow-up matters now, and your comments are invaluable. Some responses to your comments:
Thank you! |
|
Speaking of "negative outlook", now I am all negative - but in constructive way. X) It was disappointing to see that Bisq do excessive collection, I guess only Disroot stays strong. 😆 My main point here is that absolutely most banks UI show only last-name initial, so even if user has that full in Bisq it won't come up in documents/screenshots of the payment.
Wow, sounds unhealthy. =( I mean it's also a penalty.
There's quite some space for improvement yet. Tbh, I'd rely on translation engines and more happy to edit the English page to facilitate their results than create another page which sooner or later will get a consistency issue with its counterpart.
|
I am great thanks! I have fixed the type and added the link. Editing the wiki requires having a wiki account. Although I have my own wiki account I do not have the admin rights to add needed to add other users. Happy to add any changes you want though. Sending a file like you did previously was easy for me to use. |
Thanks for the summary. It is fine to keep it the way you have implemented it. CBM and USPMO do not have banks attached to them so payments never get held up for checking, returned to sender, sent from another institution. Essentially cash by mail and a blank USPMO are bearer instruments, whoever has possession has ownership. Having a name would not matter.
Thanks, that is great.
That makes sense. There is also a Faster Payments in Hong Kong that was requested to be added a while ago. Your solution avoids confusion. Will be good to see some offers when the new payment method is added.
Happy to add any changes you would like. I have never added another language to the wiki but I am happy to try. |
It is not collecting anything. There is no centralized server where the payment info goes to. No more information should be exchanged than needed. When we aired on a more privacy side (ie only minimal information needed to make the payment) it caused other issues for example:
|
@skaunov - I know you feel strongly on this issue. Can you provide a sample bank receipt here in which you were the SBP recipient? I am unsure what SBP tells the recipient about where the money came from, and that is a real issue upon a dispute. Also @pazza83 makes a good point that there likely is no last name initial if the payment came from a business account. |
|
That phrase was a joke, mostly an opportunity to mention another great team committed to good approach. I can't say I really feel that strong, but I see points for the better way, and am here to offer those. I argue that the other approach is just sub-optimal. Though maybe I just don't see something. So. I peeked at received payments. A recipient gets the phone and amount. Bank can provide some more info at their discretion: some show the id of the SBP tx (I'm really disappointed signature and public keys aren't mandatory to show.) Rarely you can find the full last name and it's probably an enrichment by the bank own data when it's their client too. I see one without any name just from another bank and its logo, from a different bank I see first+initial (without patronymic). For disputes my take is that if the phone doesn't match then it's a wrong account hence the consequences. If it's only the name doesn't match then there's appropriate penalty for that and it's hard to tell if there's something bad attempted or just a mistake (so it's up for the seller to take the risk motivated by the penalty). I took some effort to double check the concern on businesses more thoroughly, and found out there's some novel development with this. I don't see enough info on B2C yet, older sources tell that personal and legal bodies were practically disjointed. Now it's getting more interveined. |
|
Thanks @skaunov! I'm only implementing this payment method for SBP payment by telephone number. Businesses that want to provide a QR code to be paid, they're deviating from the payment method rules, and we probably should add a note on the wiki and pop-up that this Bisq payment method does not support that at this time. Whether we ever will, I'd like someone with a business account to step up and provide info. on how that works and chargeback risks. I'm still think requesting "account owner full name" is best approach for sender and receiver to provide each other, especially as @pazza83 indicated that, "minimal information" is not the Bisq policy and that the full name will only be available to the peers and mediator, not stored on any server. It's also more consistent with many other payment methods, particularly Zelle which is very similar to SBP. |
|
I mentioned QR (and its friends) only to show businesses were disjoint quite well. But if they will have phone as id and also retain charge-back capability from that realm (which is for consumers mostly) then it will be a problem to get back to. Anyway it's something to watch over several month. Not a big deal. X) Though could you outline an example when full last name helps somehow (to mediator or somebody)? (Tbh to me it feels like the single similarity with Zelle is phone number usage being literally everything else different. 🤷 ) |
|
I started modifying the names of these conflicting payment methods, and I have a small issues or revision to what we planned: I really don't like "Faster Payments System-SBP (Russia)" when I see it in app. Very long and redundant. I especially don't like it in Russian as "Система быстрых платежей-СБП (Россия)". So I am thinking to submit the revisions like this:
And for the shorthand:
I know that's not exactly consistency, but I am told there is a possibility of another "Faster Payment System" coming soon from Hong Kong (HK). @pazza83 Are you fine with this (SBP is not a country like it is on the others)? "Faster Payments" is used on a lot of transactions right now, so this change to "Faster (UK)" will be very noticeable and may be initially puzzling to some people. I also had some trouble with the translations. In French, the UK abbreviation does not make sense. Instead, the best suggestion that I came across to handle it was to use as, "Système de paiement plus rapide (GB)" with "GB" instead of "UK". |
Removed all caps of "RUSSIA" in new account pop-up and renamed existing payment method "Faster Payments" which is a similarly named payment method to "Faster Payment System (UK)", as required follow-up to to pull request bisq-network#7255 and discussed in issue bisq-network/growth#288
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 #206 (comment)?
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.)
The text was updated successfully, but these errors were encountered: