They dont answer to email and want add this.
I would like to add a further clarification to my complaint and also anticipate some of the possible responses from the operator, so that the dispute is not reduced simply to the words “if successful”.
My position is not that every single click on a Cash Out button must automatically constitute a completed settlement.
The issue is different: Rabona needs to explain which contractual rule governed the risk during the period after my click.
In my case the sequence was:
approximately €15,600 Cash Out available → I selected and confirmed it → request remained pending/processing → subsequent goal/market change → request rejected → later Cash Out of approximately €1,165 successfully settled.
I would therefore like to address in advance the main possible responses from Rabona.
1. “The Cash Out was not successful under Section 16.18.1.”
I do not dispute that Section 16.18.1 contains the words “if successful”.
What I dispute is that the provision does not explain what contractual condition may cause a request that has already been submitted while the Cash Out was available to become unsuccessful.
Simply stating that the request “was not successful” describes the final outcome but does not explain the contractual basis for the rejection.
The relevant question remains:
What specific Rabona provision states that an event occurring after my click may prevent an already pending Cash Out request from becoming successful?
2. “The only successful Cash Out was the later €1,165 Cash Out.”
This does not resolve the dispute.
I am not disputing the later approximately €1,165 Cash Out, which was successfully settled.
I am disputing the earlier approximately €15,600 request.
The fact that the second Cash Out was successful does not explain why the first one was rejected or which contractual provision allowed it to be rejected because of a later event.
3. “The market was suspended before the €15,600 Cash Out finished processing.”
If this is Rabona's technical explanation, I ask Rabona to expressly confirm it and provide the relevant timestamps.
However, such a response would make the contractual issue even more important.
Rabona's Section 16.18.1 does not expressly state that:
- acceptance is not guaranteed after the player clicks;
- the player continues to bear the market risk during processing;
- a market suspension occurring after submission may cause the request to fail.
LibraBet, which is within the same 7StarsPartners portfolio, expressly regulates this situation and clearly states that a Cash Out request may fail if the market suspends before the request has been processed.
I am not claiming that LibraBet's Terms apply to Rabona. The comparison simply demonstrates how easily such a limitation can be expressly disclosed when an operator intends to rely upon it.
4. “There was a technical or sportsbook provider issue.”
If so, I ask Rabona to provide the specific technical evidence.
I would like the rejection code, request status, timestamps and the precise technical event that caused this particular request to fail.
A generic reference to a “technical issue” should not replace the objective server records relating to my specific transaction.
5. “Clicking Cash Out does not mean that the request has been accepted.”
Even this response would not fully answer the dispute.
If there is a second approval stage after the player clicks, during which Rabona or its sportsbook provider may still reject the request based on subsequent events in the match, that stage is economically material to the player.
Rabona's Terms should therefore clearly explain:
- that such a stage exists;
- when that stage ends;
- which events may cause rejection;
- who bears the market risk during that period.
Section 16.18.1 does not do so.
6. “The processing delay was normal.”
Whether the processing lasted 10 seconds, 30 seconds or one minute does not resolve the contractual issue.
The issue is not only whether the delay was technically normal.
The issue is whether, after the player had already submitted the Cash Out, the risk of a future goal contractually remained with the player during that period.
The Rabona provision repeatedly cited to me does not expressly establish that rule.
For these reasons, I ask Rabona to provide LCB with the relevant server-side logs for bet ID 5359638430, including:
- the Cash Out amount recorded and available when my request was submitted;
- the exact timestamp when the approximately €15,600 request was received;
- the request status and duration of the processing period;
- the timestamp of the subsequent market suspension;
- the exact rejection reason/code;
- confirmation of whether the subsequent goal caused the request to be rejected.
I have requested this information directly from Rabona for several days through multiple emails. Rabona has not provided the timestamps or a specific technical explanation, and my subsequent emails have remained unanswered.
I find this lack of response particularly concerning because these server records should allow the sequence of events to be objectively established.
My position remains that, in the absence of an express Rabona provision placing the risk of events occurring after submission during processing on the player, the Cash Out should be recognised at the value displayed and selected when the request was made.
I therefore request payment of the difference between the approximately €15,600 Cash Out and the later approximately €1,165 Cash Out that was actually settled, i.e. approximately €14,435.
If Rabona agrees to resolve the complaint, I request that this amount be actually paid through the withdrawal method available on my account rather than merely credited as gaming balance.
I will consider the complaint resolved only once the funds have actually been received.
Ze beantwoorden geen e-mails en willen dit toevoegen.
Graag wil ik mijn klacht nog verder verduidelijken en ook alvast anticiperen op mogelijke reacties van de operator, zodat het geschil niet simpelweg wordt gereduceerd tot de woorden "indien succesvol".
Mijn standpunt is niet dat elke klik op een 'Uitbetalen'-knop automatisch een voltooide transactie betekent.
Het probleem is anders: Rabona moet uitleggen welke contractuele regel van toepassing was op het risico in de periode na mijn klik.
In mijn geval was de volgorde:
Ongeveer €15.600 aan contante uitbetaling beschikbaar → Ik heb dit geselecteerd en bevestigd → Verzoek bleef in behandeling/verwerking → Vervolgens doel-/marktwijziging → Verzoek afgewezen → Later is een contante uitbetaling van ongeveer €1.165 succesvol afgerond.
Ik wil daarom alvast ingaan op de belangrijkste mogelijke reacties van Rabona.
1. “De uitbetaling is niet gelukt volgens artikel 16.18.1.”
Ik betwist niet dat artikel 16.18.1 de woorden "indien succesvol" bevat.
Wat ik betwist, is dat de bepaling niet uitlegt welke contractuele voorwaarde ertoe kan leiden dat een verzoek dat al is ingediend terwijl de Cash Out-optie beschikbaar was, alsnog wordt afgewezen.
Door simpelweg te stellen dat het verzoek "niet succesvol was", wordt de uiteindelijke uitkomst beschreven, maar wordt de contractuele grondslag voor de afwijzing niet uitgelegd.
De relevante vraag blijft:
Welke specifieke bepaling van Rabona stelt dat een gebeurtenis die plaatsvindt nadat ik heb geklikt, kan voorkomen dat een reeds in behandeling zijnde uitbetalingsaanvraag wordt goedgekeurd?
2. “De enige succesvolle uitbetaling was de latere uitbetaling van € 1.165.”
Dit lost het geschil niet op.
Ik betwist de latere uitbetaling van circa € 1.165 niet, die succesvol is afgehandeld.
Ik betwist het eerdere verzoek van circa €15.600.
Het feit dat de tweede uitbetaling succesvol was, verklaart niet waarom de eerste werd afgewezen of welke contractuele bepaling afwijzing vanwege een latere gebeurtenis mogelijk maakte.
3. “De markt werd opgeschort voordat de uitbetaling van €15.600 was verwerkt.”
Als dit Rabona's technische uitleg is, verzoek ik Rabona dit uitdrukkelijk te bevestigen en de relevante tijdstempels te vermelden.
Een dergelijk antwoord zou de contractuele kwestie echter nog belangrijker maken.
In paragraaf 16.18.1 van Rabona staat niet expliciet vermeld dat:
- acceptatie is niet gegarandeerd nadat de speler klikt;
- de speler blijft het marktrisico dragen tijdens de verwerking;
- Een marktopschorting die plaatsvindt na indiening kan ertoe leiden dat het verzoek wordt afgewezen.
LibraBet, dat deel uitmaakt van hetzelfde 7StarsPartners-portfolio, regelt deze situatie uitdrukkelijk en stelt duidelijk dat een uitbetalingsverzoek kan mislukken als de markt wordt opgeschort voordat het verzoek is verwerkt.
Ik beweer niet dat de voorwaarden van LibraBet van toepassing zijn op Rabona. De vergelijking laat slechts zien hoe gemakkelijk een dergelijke beperking expliciet kan worden vermeld wanneer een aanbieder zich daarop wil beroepen.
4. "Er was een technisch probleem of een probleem met de aanbieder van de sportweddenschappen."
Zo ja, dan verzoek ik Rabona om het specifieke technische bewijsmateriaal te overleggen.
Ik wil graag de afwijzingscode, de status van het verzoek, de tijdstempels en de precieze technische gebeurtenis die ervoor zorgde dat dit specifieke verzoek mislukte.
Een algemene verwijzing naar een "technisch probleem" mag de objectieve servergegevens met betrekking tot mijn specifieke transactie niet vervangen.
5. "Door op 'Uitbetalen' te klikken, betekent dit niet dat het verzoek is geaccepteerd."
Zelfs dit antwoord zou het geschil niet volledig oplossen.
Als er na de klik van de speler een tweede goedkeuringsfase is, waarin Rabona of de aanbieder van de sportweddenschappen de aanvraag nog kan afwijzen op basis van latere gebeurtenissen in de wedstrijd, dan is die fase economisch relevant voor de speler.
De voorwaarden van Rabona moeten daarom duidelijk uitleggen:
- dat een dergelijk stadium bestaat;
- wanneer die fase eindigt;
- welke gebeurtenissen tot afwijzing kunnen leiden;
- wie het marktrisico draagt gedurende die periode.
Paragraaf 16.18.1 doet dat niet.
6. “De verwerkingstijd was normaal.”
Of de verwerking nu 10 seconden, 30 seconden of een minuut duurde, lost de contractuele kwestie niet op.
De vraag is niet alleen of de vertraging technisch gezien normaal was.
De vraag is of, nadat de speler de uitbetaling al had ingediend, het risico van een toekomstig doelpunt contractueel bij de speler bleef liggen gedurende die periode.
De Rabona-bepaling die mij herhaaldelijk is voorgelegd, stelt die regel niet expliciet vast.
Om deze redenen verzoek ik Rabona om LCB de relevante serverlogs voor weddenschap-ID 5359638430 te verstrekken, waaronder:
- het uitbetalingsbedrag dat geregistreerd en beschikbaar was toen mijn aanvraag werd ingediend;
- het exacte tijdstempel waarop het verzoek van circa €15.600 werd ontvangen;
- de status van het verzoek en de duur van de verwerkingsperiode;
- het tijdstempel van de daaropvolgende schorsing van de markt;
- de exacte reden/code van de afwijzing;
- bevestiging of het daaropvolgende doel ertoe heeft geleid dat het verzoek is afgewezen.
Ik heb Rabona gedurende meerdere dagen via verschillende e-mails rechtstreeks om deze informatie gevraagd. Rabona heeft geen tijdstempels of een specifieke technische uitleg verstrekt, en mijn daaropvolgende e-mails zijn onbeantwoord gebleven.
Ik vind dit gebrek aan reactie bijzonder zorgwekkend, omdat deze servergegevens het mogelijk zouden moeten maken om de volgorde van de gebeurtenissen objectief vast te stellen.
Mijn standpunt blijft dat, bij afwezigheid van een uitdrukkelijke bepaling in de Rabona-wetgeving die het risico van gebeurtenissen die zich na indiening tijdens de verwerking voordoen bij de speler legt, de uitbetaling moet worden erkend tegen de waarde die werd weergegeven en geselecteerd toen het verzoek werd gedaan.
Ik verzoek daarom om betaling van het verschil tussen de contante uitbetaling van circa € 15.600 en de latere contante uitbetaling van circa € 1.165 die daadwerkelijk is voldaan, oftewel circa € 14.435.
Als Rabona ermee instemt de klacht op te lossen, verzoek ik dat dit bedrag daadwerkelijk wordt uitbetaald via de opnamemethode die beschikbaar is op mijn account, in plaats van slechts te worden bijgeschreven als speltegoed.
Ik beschouw de klacht pas als opgelost wanneer de gelden daadwerkelijk zijn ontvangen.