Ratholing
The reasons we have committed to addressing ratholing are already posted in great detail in public. Our focus is on determining what exactly to do, then executing.

We want to find a preventative solution rather than a punative solution. Punishing players creates a negative experience for customers who may not know the rules. It also takes substantial resources. Cases of rules violations are rarely so clear as to be handled quickly. Players violating rules may not feel that they are doing so even if data shows that they are. Players may also feel that other specific players are violating rules based on a small number of incidents when the data shows no such long-term trend, resulting in player frustration that rules are seemingly not being enforced.

We are OK with some limited amount of ratholing type behavior and specifically want to protect it. Sometimes players find themselves in uncomfortable positions where a tough aggressive player has position with deep effective stacks. This happens both for 100bb and 40bb players. Additionally, players with small account balances may win a pot and want to split their funds up across multiple tables.

We also want to protect the ability of players to play sessions across many tables, buying in for the minimum on each. As long as they are not ratholing, this is not a problem.

This leaves us with the challenge of defining very precisely the behavior we want to end in such a way that the behavior we want to allow is not included. We need to create both a verbal definition that is easily understood by poker players and a corresponding technical definition that can be coded into our software.

We would want to do so in a sufficiently simple way, as with all of our improvements. Simplicity benefits not only development time and communication, but also simpler solutions tend to be more robust in the long run. Complexity opens up additional possibility that unanticipated behavior patterns might help players get around the spirit of the intended change.

We have not succeeded in finding such a definition that both met our normal standards of simplicity and would properly isolate the problematic behavior. At some point earlier this year, we resigned ourselves to considering more complex solutions.

Thanks to a post by 2+2er 'mme', we worked out a very precise definition. We provided an 18-page document to all player representatives that outlined the solution. This business requirements document (BRD) is what we provide to the development team when we request a new feature. We had been through many rounds of review and edit on the BRD already.

The basic premise of the solution is that we track players' stack sizes when they leave tables and then enforce appropriate minimum buy-ins when they re-join other tables. Joining a table creates a 'stack identity' for that table type. For example, if I were to sit at a 40-100bb table with 40bb, then leave the table with 67bb, I would now have 40-100bb stack #1 set at 67bb.

Each player would have a maximum number of stacks at each table type, with table type defined by buy-in range. The maximum number of stacks would be equal to a player's table cap (for regular tables) and table cap divided by 3 (Zoom). This way a player could start a full maximum tables session with minimum buy-ins, but if they left any table with more than minimum buy-in, they would then need to re-use the same stack identity when buying into another table of the same type.

For example, if I buy in to 24 40-100bb tables with 40bb each, double up on one to 80bb and leave, I would then have to buy in for at least 80bb if I then tried to join another 40-100bb table. Let's say I do this. Then if I lose 20bb and leave with 60bb, the next table I would join I could buy in for 60bb. This all assumes that I have stayed on the other 23 tables the whole time; if I had left those tables, I would be given the option to buy in for the smallest number of bb available on one of my stack identities.

Zoom would be considered a separate table type as it is 50-100bb, but PLO and NLHE 40-100bb tables would use the same stack identities.

We have accounted for angleshooting as best as we can predict. For example, if you buy into a table with significantly lower stakes than the one at which you created your stack identity, you are still bound by the minimum number of big blinds at buy-in but you cannot reduce, only increase, the size of the stack identity when leaving the tables. This prevents players from doubling up at high stakes and then reducing their minimum buy-in back to 40bb by losing money at much lower stakes.

The identities expire after a set period of time that is configurable. Configuring this period of time is challenging. The longer it is the more effective we are at preventing undesired behavior, but the more likely we are to be prohibiting behavior that we want to allow.

Our current thought is that the identities would need to set to expire after 18 to 20 hours. In this way a player could buy in at 24 tables for 40bb, play a full session and build big stacks on them, and then return the next day to do the same. 18 to 20 hours seems more reasonable than 24 as players can't be expected to start their session at the same exact time each day.

The downside of this configuration is that it does allow more ratholing than we might like from those who choose to take full advantage within the system. A player with a 24 table cap who likes to play only 6 tables at a time and is willing to play both Zoom and regular tables could get quite a few ratholes in per day before hitting their identity cap for both table types.

There are different opinions as to whether a 6 tabler ratholing 3 times is doing anything functionally different than a 24-tabler who joins all tables simultaneously and then leaves each table after doubling up. The net impact on the rest of the playing pool is the same, but the timing of each action seems more like ratholing. In any case, this behavior would be allowed under the system.

There is also a concern with players who have increased table caps being able to execute ratholes quite effectively. We can't a smaller number of stack identities than the player's number of max tables. If a player had 16 identities and a table cap of 24, what would their buy-in options be when sitting down at the 17th table?

Players have suggested that proactively lowering table caps for players who are not making use of their maximum number of tables concurrently would be one option. Some would suggest we should do this not just for players with caps above 24, but also for those with caps of 24 who are only playing 12. I am skeptical that this could be implemented without creating more problems than it solves. Players change behavior from time to time; a player who has been 8 tabling for years without causing any trouble may not be pleased to find that they are not able to try to jump up to 16 tables if the decide they'd like to. We have a lot of customers; reviewing such cases manually is not a desirable solution.

We don't think that multi-accounting to get around the restrictions is likely to be a big problem as VIP rewards are an important income source for mass multitabling ratholers.

It's hard to describe an 18 page solution in a forum post, but the above should give you a good idea of how it works and its identified weak spots.

We are currently doing significant technical investigation to identify what % of ratholing occurrences this would prevent if implemented today, based on a loose definition of ratholing. As long as the % is meaningful and no better solution presents itself, we will move forward.

We had hoped to implement this solution in the first half of the year as I have stated multiple times and we have been planning to do so, but it is clear at this point that we are not going to hit the deadline. We are doing everything we can to get the solution ready to go over the summer. It's extremely disappointing to me that we are missing our goal here, as I know it is disappointing to many of you.