Implementation of protection tools: strengthening Account Age by requiring payments from 2 Bank Accounts #93
Comments
|
Given the number of proposals now out for protection mechanisms, should we have a call to discuss where we stand, and what this particular one is all about? I can see it being confusing for people to provide feedback just as it is. How about next Tuesday, 28 May? Time TBD but would have to be at or before 5pm CET. Feel free to read through this proposal, ask questions, etc. and we can talk through everything then to determine a way forward. |
|
Next tuesday at 5 PM is ok with me.
This assumption is subject to the idea of adding a pre-trade step where the buyer and the seller can communicate through the p2p chat, which would help fighting stolen/bought IDs and money launderers |
|
Over all I approve. I think focusing on getting this done makes sense and perhaps continue other discussions on other features in parallel. I find the 'Account age calculation procedure' section rather difficult to understand, if it's possible to simplify it that would be a good thing. The whole banning concept relies on someone having the ability to trigger bans. It would be nice to be able to not have such a single point of authority, but it's hard to see how decentralizing this decision would work considering the urgent time frame of stopping an account from continues scamming. The bans would mainly be on account(agewitsesses) rather than onion addresses I assume since it's possible to move accounts between onion addresses. A graph to explain who is considered suspicious or not might help to clarify the intricate relationships between scamming brothers, parents and cousins. Such a mischievous family. |
That´s because it is written having edge cases in mind and thinking from the point of view of the Bisq client that has to verify everything by itself. This procedure basically means that payment accounts only begin to age from the date when an old enough user has confirmed a trade with 2 payments from different banks.
Fully agree. Steve and I initially thought of proposing a decentralized system. We have worked through it quite in depth and we think it is certainly possible but it would be much longer to implement and since it would be based on bonding BSQ we thought to better leave it out and wait until the trading protocol also upgrades. The mischievous family :
|
|
Agree with having a call to discuss all proposals. Next tuesday at 5 PM is ok. My main concerns with this as with similar proposals are: 1. Don't break what does work to fix what doesn't. 2. Keep it voluntary. 3. Don't ignore impact on UX and onboarding. 4. KEEP IT SIMPLE! Many of these mechanisms could even be built on top of Bisq instead of in Bisq. |
A way to keep it voluntary would be to keep internally the current account age for trading limits (or maybe allowing to gain just one step after one month). But the account age shown to other users would work as suggested in this proposal. So it would be up to the other users the decision to trade or not with 0 account age users. Again direct communication between traders would be very interesting here as an old user could be comfortable to trade with a 0 account user if both privately agree for whatever reasons (for example local whitelisting methods when implemented).
My view on that is that there is a high chance that scammers are not coming to Bisq because of low liquidity. And unfortunately the harm of just a few dishonest trades, even if just every once in a while, could be very big. The good thing of your suggestion of implementing the measures proposed here as optional, is that if we keep for long enough, we might have a reasonable feedback of what works and what doesn't work. |
|
Regarding the banning procedure, I strongly believe it should be implemented in any case. Now with arbitrators and in the future decentralized once arbitrators are gone. @flix1, what´s your opinion on this? |
I prefer decentralized solutions such as p2p blacklists to banning. However banning is simpler and as long as we have arbitrators it makes more sense. So I agree with banning for now. However when arbitrators are gone it will be too dangerous to have a centralized authority (DAO role?) with the power to ban users. It would be an obvious single point of attack for any regulator that wants to impose censorship. It would also be dangerous to allow users to report/ban as this mechanism creates perverse incentives in a competitive market. A user who wants to corner a market could easily game this feature. So long term we need to come up with something better. Researching cell systems is probably a good start: |
The basic idea is that the BTC buyer could defend by challenging the seller through a predefined trade with highest possible security deposits (or with BSQ bonding), and involving a randomly selected triggering user. The accusation would put the Buyer on a temporary blacklist which would downgrade its account age to 0. If the buyer is able to make the 2 payments again, he would be removed from the blacklist (the Seller would lose the bond if applicable). If the buyer fails to overcome the challenge, he would lose the security deposit / bond and would be permanentely banned. The seller could have his account age rejected to 0 or even be banned if his accusations are succesfully challenged more than 1 or 2 times. The DAO wouldn't be involved. This is the very basic concept. The full idea deals with quite a few nuances and edge cases. But since this proposal is already difficult, I suggest to discuss this after a decission on this proposal is made, or in a separate thread if you agree. |
@mpolavieja are you referring to this? I think it might already be in the proposal in the "Blacklisting and Banning Procedures" section:
|
|
My bank is very curious about my transactions using Zelle. On just about every trade I'm get called asking what the transaction was for. I have a dedicated bank that I only use for Bisq. With the new account age process, it looks like I'll need to go shopping for another bank and payment type. My fear is the bank(s) will get wise to what I'm doing and suspend the account. If I have to establish a new bank account then, I'm back to square one with the accounting aging process. I bet you can read my mind if this ever happens. The bonding process sounds good to me. I'd more willing to put my BTC/BSQ at risk if I don't honestly complete the trade contract. The bonding process would be less headache for the end user than that which is being proposed. I'm finding it difficult to trust Bisq to be there when I need it to conduct trading. There always some weird issue that comes up that is blocking for one reason another at the perfectly wrong time. It is not always a Bisq issue that is getting in the way. I'm just saying this so know my experience and that you don't forget to put on your customer shoes and look at the solution from a customer who wants to use Bisq for active trading (not Hodling). Bisq is still the best P2P solution, it just needs to attractive more active traders. |
|
The fiat banking system is treating its users like childs and burglars, with tons of regulation/protection/limits/delays etc. With bankers experts knowing better than users what is good for them and what is not good for them. I monitor the EUR/BTC, USD/BTC numbers daily. Everybody participating to this discussion should do that. The decrease is really worrisome. We are really hurting hard our poor customers and of course some go away. |
|
You could say the exact same thing about any software or service that enforces 2FA / multisig. We must not confuse basic security standards with KYC. This proposal is about 2FA, and if possible it will be implemented as optional, so we will see if users use it or not. |
@HarryMacfinned I agree with a lot of what you are saying. We should not be making decisions for users like a company or bank. That's the whole point of being decentralized. Our role should be to build tools that allow users to protect themselves. Not to be in charge of protecting them. |
@cadayton It could be an overkill to set up a new account just for making the first secondary initial payment. It shouldn't be a problem to use any other bank account you already have to make that one single payment. Unless you want to use that secondary account as a Bisq back-up in case your bank closes your main account for whatever reason. The secondary account would age the same than the main account so you could keep trading with the same limits with the secondary account. Furthermore, at the beginning of the proposal it is suggested to introduce a pre-trade step where users could freely and privately agree on how they want to conduct the trade (not necessarily requiring a second bank account). However, the technical feasibility of adding pre-trade step needs to be assessed carefully as it could be rather complex. |
|
And as a more general comment, regarding the UX of having a network level account age parameter, I think that if we don´t have that (or what we have is not reliable enough) we all agree that a decentralized local whitelisting should be implemented. Comparing those two alternatives it is not clear at all that the decentralizaed UX is better as you would have to repeat whatever process you deem necessary with every single new trader and it could lead to fragmented and siloed liquidity. The account age procedure suggested here is just a one-off hassle, so it is probably more balanced towards UX than to security than the fully decentralized approach.
Ok @flix1, but we should be careful not to annoy users with too many options. Users come to Bisq to trade not to figure out security. As an example think about the simplicity of hardware wallets vs. the complexity of glacier. Because as for now Bisq is not only a protocol but also a front/end UI, we need to find a balance between "HW approach" and "Glacier approach" (i.e. a balance between UX and security). |
|
I like having this as an option among other protection tools. For a normal user that wants to just buy some BTC and don't care about continuous trading this could be an easy way in with limited risk of having their bank accounts closed or otherwise bothered by their masters. For those that don't have multiple bank accounts or have other limitations we should think of other methods as well. Using BSQ bonds is a really neat thought but I think it's still too early for that. In case I'm wrong and we decide to add BSQ bonding as a way to perform the initial trade there are quite some work to be done. We have already thought a bit about using bonding as a trade protocol, it's rather complicated and I'm convinced it's too early for that now. For just one trade it would be more feasible, but the bond would still have to be locked up for at least 1.5 DAO cycles (1.5 months) to allow time for it to be confiscated. Perhaps this could be a way to towards the bonded trade protocol. |
|
I think that BSQ bonding is a great idea but as you say BSQ and the DAO are not mature enough and bonding BSQ is also a barrier of entry for onboarding UX, which is one the main drawbacks also raised for this proposal. Moreover, involving the DAO on confiscating as a standard procedure sounds to me as an extremely difficult decision to make. So if we want to move forward and unlock the current situation with the trading limits, I suggest to focus the discussion on approving, modifying or rejecting this proposal. In that respect, should we first make a final decission on finally approving the priorities proposed at #91? |
This, in my mind, is the critical decision we will need to collectively make: peer-to-peer with repetition or network-wide with convenience. [I scheduled a call to discuss this stuff for Tuesday at 17 CET: https://github.com/bisq-network/growth/issues/132] At this point, I think we've got adequate ideas that indicate how each one would practically turn out for users. To address cadayton's points: if we stick with the network-wide approach proposed here, perhaps we broaden the measures required to start account aging to some of those included in #83 (particularly method 2, which I just updated to not require PGP anymore) so users aren't required to open/use a second bank account. |
|
Another piece in this puzzle I think we should consider is payment methods themselves. Remember that cash-based payment methods will not require any of this mess. Maybe we should consider adding new payment methods:
(2) is particularly interesting as it seems almost as good as cash, provable, and relatively quick/convenient...it may be able to get by without any onerous requirements. Note that I haven't thoroughly researched any of the items above...I guess my point here is that the proposed measures (in some form) may be necessary for the payment methods they're intended for. Perhaps new payment methods can get by without needing them. |
|
Overall, we need to find a balance between on-boarding UX and protecting already on-board traders, specially active traders. Active traders are both the strength and the Achilles heel of Bisq. Active users are the ones that have a huge chance of getting hit by scammers. If we get a scammer every once in a while, it will most likely hit active traders who always post offers, so only a few scamming events would lead to lose a lot of liquidity if active trader's accounts are slowly but relentlessly getting closed. Moreover, as active traders are very easy to spot by banks, even if the account of the active trader is not closed, all the accounts that have traded with him from the same sender bank of the scammer are at high risk of being closed (this has already happened with some banks). Users that initially join with the clear idea of active trading might be careful since the beginning. But users that become active without planning might be risky if Bisq does not easily take them through a secure path, specially considering that most Bisq users are honest which might very easily lead to relax security as most trades are settled without any problem at all. |
|
Regarding optionality and the pre-trade stage this is another possibility:
Then, the Seller Triggering Account could require zero age account buyers one of the following:
Option 3 is important for very active traders or market makers. Bisq's liquidity network needs those type of users to be very careful from whom they receive bank payments. For Option 1 it would be best to enable a delay for releasing the BTC such as the following proposed by @ManfredKarrer in #77:
|
|
Agree with most of the comments...
|
In my country, cashier's checks are treated exactly like paper money. If you lose them then you lose the money. The withdrawal from the account is made immediately upon requesting the check from the teller. Just FYI. |
The problem with the clock icon is, that we want to communicate three states with it:
This states are not always connect to time (only for our first account signing implementation), but also depend on the kind of account signing. So it might be a little bit misleading in the end. I do agree that we need to take care not to communicate too much trust as there won't be a system where we could guarantee that you won't be scammed (a trusted account could also be stolen later). I will think about a different icon or no icon at all (as suggested by @flix1) to prevent this misunderstanding of trust. |
|
Maybe we should use different icons for these states: @mpolavieja @m52go what do you think? |
|
I still like the most the clock in different colors. I suggest a yellow clock for the first state, a white or gray clock for the second state, and a green clock for the third state (maybe substiting the clock hands by a checkmark that exceeds the clock circumference). Something like this (but not as ugly as this):
From a onboarding UX perspective, probably the most important thing is to easily spot accounts that have the ability to sign, so new users can find them and get signed by them. IMO the green color will do most of the communication. |
|
Yeah my intentions with the clock weren't so much to communicate exact status then to give the user a rough idea of the "risk level" of a particular peer, and to show additional details in the account-details tool-tip. Perhaps we get rid of the clock and simply use a colored dot with an exponent/superscript part to indicate more specific status? Kind of like Manuel suggests above, just without a clock...there could be check marks, plus signs, question marks, etc to complement the colored dot to indicate specific account status (e.g., like Slack's status icons). That way, the user can will know an account is relatively safe when seeing this (for example):
And they'll know to be a bit more cautious when seeing either of these:
These are ugly, but hopefully they demonstrate conveying the basic message from the icon, and then the user can look up more details in the account tool-tip. Or we could just use colored dots exclusively (without superscripts) and explain in tool-tips, perhaps in red-yellow-green. We wouldn't have enough colors to indicate every precise status, but I don't think it would be a bad thing to use yellow and red for multiple risk levels. Personally I still don't find these icons very intuitive. I mean, I get it, after the explanation, but I think it would be best to use more intuitive symbols for the UI so new users don't feel like they need to look up icons that they don't immediately recognize. |
I like this symbols, as long as the meaning of the symbols is close. Can we use this icons and colour? Colour-only icons aren't good for colour blind people. |
|
I'm finally back on the UI part of the account signing. After coming back to the current state I think the only thing we need to communicate on first sight is attention for accounts that are not signed and accounts that were signed but are not able to sign other accounts. So I suggest we use following:
So although we have five states:
I would display on first glance only warning for every account that is not able to sign. |
|
I very much like the idea of having multiple states and a number (time since signing). It gives users additional information and with it the ability to discriminate. Imagine we have a coordinated scam starting on a certain month with multiple signing accounts... having the age would allow discriminating accounts signed since the scam started. Or if the system has to be reset for whatever reason... arbitrators could sign a number of accounts to ensure a fast turnaround and users would be advised to discriminate against newer "signed by peer" accounts. Of course no system is perfect against scams... but account signing age + account age would provide a lot of valuable reputation-like info. (My favourite data about an account would still be nº of successfully completed trades, if it ever becomes possible). |
|
Fiat accounts view could look like this |
I think it is a very good idea to keep it simple. |
|
And within each of your accounts that require signing, you will find additional information. Btw. I'm already implementing this on top of @sqrrm's work. So it kind of the real deal already 😄 |
|
@ripcurlx this is great! Really like the simpler approach...it looks great, and doesn't leave out any details. One very small suggestion: how about adding the exclamation/check icons to the |
Will add it 👍 |
|
@m52go @mpolavieja @ManfredKarrer As it just came up while working on the account signing feature something to discuss: ATM we have for altcoins no limit (2 BTC per offer) and for all non-risky payment methods within the first 30 days factor 0.25 (e.g. for Perfect Money 0.25 BTC) between 30 and 60 days factor 0.5 (e.g. for Perfect Money 0.5 BTC) and after 60 days factor 1 (e.g. for Perfect Money 1 BTC). Now we introduce for high risk payment methods (e.g. SEPA) the account signing feature. Until an account is signed it will have the limit of 0.01 BTC. 30 days after the account got signed we'll lift the 0.01 BTC limit. So @sqrrm raised the legitimate question if we want to lift the limit after 30 days using immediately factor 1 (e.g. 0.25 BTC for SEPA)? |
|
I think it depends on the verification mechanism. For account signing verified by 2 factors, I don't see any reason not to lift limits all the way after 30 days. |
But in this next release we are going to have only 1 verification factor (not 2FA yet), correct? In my opinion I´ve always thought it is too harsh to have the account signed and still have the 0.01 limit for 30 days instead of at least 0.0625. I think it will be quite discouraging for new honest users. But I assume that is the consensus and it helps to have chargebacks under control since we decided not to have a delay in the payment for new accounts. So I think that rasing it to 0.25 after 1 month is ok. |
I assumed the first iteration would include payments from 2 bank accounts as a verification mechanism. Would be good to have this clarified...I looked through old posts but it's been a while since we discussed this in detail. |
Yes, we'll try to finish everything off for the 1 verification factor. If everything looks fine and we would be good to go, we still can decide if we want to add the 2FA for this release as well or if it will be in v1.2.1. |
|
@m52go @mpolavieja Currently we have the account signing by arbitrators/counterparties implemented. I suggest we leave 2FA for a later release as we want to get something live as soon as possible to allow for proper fiat trading again. The limits haven't really been settled from what I can see. What I did so far is: Any seller and buyers with accounts that are not high risk (low liquidity currencies):
Buyers with high risk accounts:
I think counting time from signing is reasonable. We can change the limits but we should do it now before release or it might cause quite a bad user experience if we do it later. The reason for the asymmetry regarding buyers and sellers of high risk accounts is to keep what we currently have and not lower any limits. Accounts will be able to sign others two months after getting signed. Arbitrators will sign accounts created before March 1 2019 to act as root accounts for signing. Accounts signed by arbitrators will be able to sign others from day one. |
I think it is a fair decission Why is it 0.0625 BTC instead of 0.125 BTC for high risk accounts signed more than a month ago? Given that 2FA is not going to be activated in this release, will it be possible for old traders to filter out trading with unsigned accounts? |
|
For the values, I chose 0.0625 BTC since if we're having a limit it should be quite limited, otherwise we might as well go with 0.25 BTC one month after signing to avoid confusion. Not a strong opinion on that though so we can change it to 0.125 if that sounds better. The UI will show the status of accounts in the order book. Unsigned, signed X days ago, and if they can sign other accounts. |
|
Don´t have a strong opinion either, just thought that having the account signed for more than one month, it would make sense to have 0.125 before 0.25 But if you guys really have doubts on this, and since we are dealing with protection (security) it would be wiser to stick to the lower limits and leave it like that for now, and maybe think of a different approach when 2FA is implemented. |
I think I would go directly to 0.125 not to punish the users even more. I don't think we get so much more protection by only allowing half of it. |
|
Now changed to 0.125 (or rather, factor 0.5, which scales with the max trade amount). |
|
This proposal has been partially implemented. 2FA still pending. |
|
@mpolavieja maybe we should keep the ticket open until 2fa is implemented, or is there a separate ticket for that? |
and others
This proposal is designed to protect users against scammers using stolen bank accounts. To protect against scammers using stolen identities and money launderers, we are evaluating the idea of adding another step in the trading process where a buyer can assure the seller using various verification mechanisms (like those in #83) before the sellers' payment details are ever shown to the buyer. As this change would require more considerable development work, we leave it out of this proposal.
We strongly believe P2P chat is a critical part of achieving protection against both types of scams, so we highly recommend implementing that as soon as possible—details below.
Introduction
This is a proposal for trade protection mechanisms from @mpolavieja and myself, and as it is the number 1 development priority outlined in #91 by @ManfredKarrer, we would like to discuss it with the community before writing a tech spec.
We tried to integrate the most robust ideas from previous proposals #77, #78, and #83, and leave some of the more significant mechanisms for future implementation (see note above).
As we think it is important to move forward quickly, if you clearly don’t approve this approach please just down-vote it and write a short comment on why you don’t like it, we kindly ask not to propose alternatives within the comments for this proposal (please submit a different proposal). If you like the core idea of this approach but you want to suggest improvements, changes or corrections, please comment.
Goal
The goal of this proposal is to strengthen the account age concept, as it has been already proven that it does not deter scammers as it was initially expected. Keeping it unchanged would be irresponsible so we have to either downgrade it to a local scope parameter or strengthen it if we want to maintain its network (global) scope.
The strengthening is based on the very basic concept that payment accounts would begin to age only if certain conditions are fulfilled. These additional conditions should not be interpreted as a reputation system. They are just about account age, and despite the added conditions, account age will still mean just that: Account Age, and nothing more. As such, it is not any bullet-proof protection mechanism, so due diligence of each trading peer will still always be required.
Moreover, this protection measure is fully compatible with other local/P2P protection developments, such as not revealing seller payment account data to the buyer until the seller has somehow verified the buyer (see proposals #90, #83 and #79), negative reputation system (see #27) or a LinkedIn-like relationship (see @flix1's proposals, like here).
Assumptions
New users are incentivized to trigger their account age above zero, so they can enjoy higher trading limits.
It is unlikely that a scammer manages to control two different bank accounts from different banks from the user.
This proposal does not provide prevention measures from a scammer stealing or buying IDs and opening several bank accounts, following the rules and doing real fiat trades in order to gain account age and become a user that can trigger account age for other users. However, this proposal provides a procedure to immediately abort corruption of the account age parameter once the illicit activity is detected.
UX impact overview
Most trades would not be affected at all by this implementation. For new users there is a one-off UX drawback. With respect to the current UX experience this implementation would involve the following changes on UX/UI:
A new user would need to set up 2 accounts and point to a secondary bank account within his main account configuration, if he wants his limits to go up.
A new user would have to understand that he needs to make a trade with an old user in order to begin to gain higher trading limits.
Old users need to understand that when a new user wants to trigger their account age with them, the payment is split in two and they have to verify both payments (same name, different banks).
Once it is triggered, the account age parameter would work the same way is working now from UX pov (we need to internally handle a subtle exception for accounts created between 1-March-2019 and the date this implementation is deployed)
A procedure for banning and blacklisting users needs to be implemented. The UX of this procedure is similar to that of current disputes with arbitrators.
Implementation overview
This implementation applies to all bank account payment methods and it is based on payment accounts beginning to age only if certain conditions are fulfilled. For this purpose we need users that perform the role of “age triggering”. For a payment account to become age triggering for other accounts is just a matter of time and not being banned (i.e. not being accused of scamming). Users don’t have to learn or understand how their payment accounts achieve that status. It is a passive role. It is new users who are incentivized to reach them.
This proposal could be improved by optionally offering different conditions to trigger account age, or by additionally requiring more conditions to trigger account age. Ideally, those additional conditions should be verifiable by third parties. As a first step, we strongly believe that the trader P2P chat should be implemented along with this proposal so sellers can freely decide how to verify users, and that would be a really helpful feedback on what verification methods should we implement.
Account age would be calculated and displayed individually for each payment account, but when a payment account is banned, all “brother” fiat payment methods from the parent onion address will be also banned.
A bootstrapping procedure to enable a curated list of triggering users could be done, but it is not completely necessary as we could assume users older than 1-March-2019 as triggering users. If something goes wrong, the banning procedure should kick in.
All the terms used in this proposal are technical terms (triggering user, triggering account age, etc) in order to be as specific as possible. Those terms are not necessarily intended to be used for the UI.
Account age calculation procedure
When enforcing the trading limits or interacting with any trading peer, the Bisq client would check the following:
If all of the above are fulfilled, the account age of the peer is calculated by verifying the witness data of the peer (witness data would also include the necessary data from the triggering user).
If any of the above conditions is not fulfilled the account age of the trading peer would return 0. Note that if the onion address of the triggering user is in the blacklist, all its “sons” (“brothers” and “cousins” from the alleged scammer account) are automatically under suspicion and de facto included in the blacklist.
Account age triggering procedure
The following prerequisites are needed:
An option should be added to payment accounts to select a secondary payment account from the other accounts configured by the user. The name and last name must be the same for the two payments methods and Banks must be different. This would be an “age triggering account”.
The buyer must use a “triggering account” if he wants his account age to be triggered.
Unlike it is implemented now, account age of risky fiat payment methods would remain at 0 until the user conducts a trade as a BTC buyer with fiat that fulfills the following:
If all the above are fulfilled, the account age witness of the buyer would be generated using both the private key of the buyer and the seller and including the account age witness of the seller (from now on Triggering User).
If the buyer was in the blacklist as a suspicious “cousin” and he successfully overcomes the above procedure, he will be removed from the blacklist. However, for these cases the seller could require more details from the buyer, the P2P chat for traders would be very helpful here.
To avoid strong disruption on the network (i.e. too many “cousins” being suspicious), each triggering payment account can trigger account age for a maximum of 3 new payment accounts. A maximum of 1 per week (if it is possible to implement)
We suggest a longer time limit of 21 days for this type of initial trades, so the seller can gain a bit more comfort that if chargeback occurs at least he is not going to lose his BTC and the victim will recover his money. This could be lowered in the future if additional verification methods are added.
Blacklisting and Banning Procedures
As stated in the Introduction section, the account age parameter is not bullet-proof so we cannot implement this proposal without a blacklisting procedure. This procedure is a must.
Arbitrators would manage a ban list for permanent bans and a blacklist for suspicious triggering users. In the future blacklisting could be done without arbitrators as well.
For now, the procedure would be as follows:
The seller selects the conflictive trade and clicks the dispute button to initiate the procedure. Now the dispute option has to be also enabled for settled trades.
The user explains to the arbitrator, and if the arbitrator thinks the complaint is legit, he asks the buyer to send back the BTC if he has received the money back.
If the buyer does not respond, or if his answers are suspicious, then the arbitrator includes the onion address of the buyer in the ban list so he cannot trade anymore. The onion address of triggering user of the buyer is included in the blacklist so he cannot trigger account age for any new user. If the triggering user was already in the blacklist, then he would be totally banned from all activity.
By including the triggering user, all “cousin” payment accounts are de facto temporarily blacklisted so they need to overcome a new age triggering process to get removed from the blacklist.
As a general rule, the banning / blacklisting procedure has to be categorical. The arbitrator shall not hesitate to ban the buyer if the seller provides enough proof of the chargeback. Only if the arbitrator suspects that the seller tries to unfairly slander the buyer he should refrain from banning. Internal guidelines for the arbitrators will be prepared.
The text was updated successfully, but these errors were encountered: