BeastPay24 is a young exchange service that bills itself as a "semi-automatic crypto exchange 24/7" with an emphasis on a wide range of directions and its own AML screening. The lineup really is out of the ordinary: besides the usual crypto (USDT on various networks, BTC, ETH, XMR, XRP, SOL) they claim fiat-to-fiat directions, bank accounts and cards, plus PayPal, Revolut and SEPA Instant, and a separate Latin America line (MXN, ARS, COP, PEN, BRL, with mentions of Pix, SPEI, PSE and Bre-B). The site has a personal dashboard with registration, a news section, a reviews page and a separate paid AML checker (10 checks for $5, 20 for $9, 50 for $20). Operators are said to be available from 08:00 to 00:00 (UTC+4) with no days off; exchange requests can be created around the clock; contacts are Telegram and email. Technically, the site is built on an off-the-shelf exchanger script: the footer says "Powered by lara-script.com" and "Protected by lyxonn.com" — so it's not an in-house product but a boxed solution for exchangers, which in this industry is more the norm than the exception.

The service's history is very short. The domain beastpay24.com was registered on June 25, 2026 (registrar Cloudflare, NS Cloudflare, owner data hidden via Cloudflare privacy, registrant country — RU, paid up until June 25, 2028). The thread on Bits.media was created on September 2, 2026, on MMGP — September 1, and the service was added to the Monik monitor on September 13, 2026. Meanwhile, the site footer reads "© 2016-2026" — meaning the claimed age and the actual age don't match. A curious detail: in headlines and promo texts the service calls itself "BestPay24", while the domain and brand are "BeastPay24" — looks like a typo that stuck in the promo materials, but for a service that asks you to trust it with your money, it's a small thing that immediately catches the eye.

Analysis of the regulatory approach, rules and terms

BeastPay24's document package is surprisingly extensive: a user agreement with 11 sections (plus a separate AML/KYC block) and a separate "AML/KYC Policy" with 9 sections. In places it's written carefully and to the point — there's a risk scale, a list of documents, phishing warnings. But that's exactly where most of the problems are concentrated: several clauses directly contradict each other, and one block looks openly unfavorable to the client. Below, in order.

Who provides the service and on what terms?

• Agreement preamble: "The Site Administration reserves the right, at its own discretion, to update and change the text of the Agreement without notifying Users. The new version of the Agreement takes effect immediately upon publication".

The rules of the game can change at any moment — including when your money is already with the service. Users are expected to keep track of new versions themselves.

• Clause 1.8: the definition of an exchange request mentions a "Contractor" ("terms of using the Service offered by the Contractor"), even though the party to the agreement throughout the document is the "Service".

A terminology mismatch — looks like the text was assembled from different templates. Not critical on its own, but it shows nobody proofread the document.

• The legal entity isn't named anywhere — not in the agreement, not in the contacts, not in the footer. No company name, no registration number, no address, no applicable law, no dispute resolution procedure. It's unclear who you'd file a claim against, and in which jurisdiction. In WHOIS, the domain owner is hidden too.
• Clause 3.2: "The Service offers its services to all Users and doesn't verify Users right to dispose of these funds".

The service rules out basic verification upfront, even though at the same time it rolls out a strict AML/KYC framework. It looks like a mismatch between the declared strictness and the actual "we're not responsible for this".

• Clauses 3.4 and 4.2: operators are available from 08:00 to 00:00 (UTC+4); "The Service offers its services according to an established internal schedule".

The thread title on Bits.media promises "crypto exchange 24/7", while the rules talk about operators working hours. Only request intake and auto-exchange run around the clock, and that's worth keeping in mind: anything disputed waits for business hours.

KYC — the main contradiction in the package

• Clause 6.3 of the agreement: "Transactions don't require mandatory verification".
• Clause 6.4: "The Service doesn't request personal data, except in cases provided for by clause 8.6 of this Agreement".
• Clause 8.6 and clause 10.7: "To recover assets that failed the Service's AML check, the User must complete full identity verification (KYC)".
• Clause 4.4: in case of suspicious actions, the service "may delay the payout, require additional identity verification and carry out an internal analysis of the funds used by the User".

So you get the combo of "no mandatory verification" → "but to get your own money back — money that failed AML — you must complete verification". Formally, it's not a lie: we're talking about verification "for recovery", not "for exchange". But in practice, a user who sent coins and got a "risk above 70%" status ends up exactly at the fork that clause 6.3 was supposed to spare them. It's a classic fork in the road, and whether it was put into the document deliberately or not — I won't judge.

What exactly can be requested (clause 8.7 of the agreement and clause 5.2 of the AML policy): full name; photo/scan of a passport; driver's license; other identity documents; proof of residential address (a utility bill or another document with a stamp and address); photo/video selfie with a passport in hand; e-mail; mobile phone number; a written explanation of the source of funds specifying specific assets, the transaction, date, full name and signature; if necessary — screenshots and video confirmations. Separately — clause 5.3 of the AML policy and clause 8.7 of the agreement: a photo of a bank card against the background of the Beastpay24.com website, with the owner's name and card number readable on the card.

That's a very heavy set — from a passport and a selfie to a signed written explanation of the source of funds. The requirement to photograph a card against the website with a readable number deserves a separate mention: such a photo is by itself sensitive payment data, and handing it over to a service with no legal entity behind it is a decision to make with your eyes open. To be fair: requirements like these are common among exchangers today — it's not a unique practice, it's an industry-wide one. But at BeastPay24 it coexists with the public claim that "verification isn't mandatory" and that combination is the most unpleasant part of the document.

• AML policy, clause 8.2: "The User must provide accurate data when creating a request and must not use anonymous proxy servers or other means of hiding their data in order to circumvent this Policy".

Formally, it's a ban on using VPN/Tor "to circumvent the policy", but the wording is broad enough that the mere fact of connecting via a proxy could fall under it. For a service dealing with crypto and international directions, that's unusual strictness.

Personal data: promises and caveats

• Clause 6.1: data is transmitted over an SSL channel with a 256-bit key length.
• Clause 6.2: "The Service doesn't share personal information with third parties".
• Clause 7.2: "The Service may provide this information only upon request by authorized state bodies, officials or Payment System representatives with legal grounds for doing so".
• Clause 4.16: "The Service has the right to engage third-party contractors to fulfill its obligations".
•  AML policy, clause 5.4: data "isn't transferred to third parties, except in cases provided for by section 7" and section 7 (clause 7.1) is precisely the transfer of information about the user and their transactions to state bodies, officials and payment system representatives.

Clause 6.2 taken at face value and clause 7.2 with AML section 7 contradict each other. "We don't share with third parties" and "we share upon request from payment system representatives" are two different statements. Legally, the second one wins, but the user reads the first. Also worth keeping in mind is clause 4.16: third-party contractors are engaged and what exactly gets passed to them isn't spelled out anywhere in the documents.

• Clause 7.4: "The Service isn't liable for third parties obtaining information about the User's activities in the event of a system breach and data being obtained by third parties".

The promise of 256-bit SSL in clause 6.1 and the disclaimer of liability for leaks in clause 7.4 sit side by side, and they should be read together.

• Clause 11.1: the service "may send to the User's specified e-mail information about the status of the exchange process, as well as other information, including promotional content".

Consent to promotional mailings is baked into the acceptance of the offer.

• Clause 11.3: creating a request automatically counts as consent to all documentation on the site, including documents that may be changed without notice.

A vicious circle, but formally legal.

4.24 Confirmation of receipt of funds

This is the block you should read carefully before sending any money.

• Clauses 4.24.1–4.24.2: the final stage is the service receiving from the user a confirmation of crediting. Confirmation is "any unambiguous action or statement by the User indicating the fact of crediting, including but not limited to: a message in the support chat, a letter from the email specified in the request, pressing the corresponding button in the automated system, as well as providing a screenshot of the account or a statement".
• Clauses 4.24.3–4.24.4: from the moment such confirmation is received, the service's obligations are considered fulfilled "in full and properly"; the request is considered completed with no possibility of revision; the service is "fully released from any liability for the further fate of the transferred funds, including… their subsequent debiting, blocking, payment reversal, erroneous crediting, as well as any actions or inaction of banks"; and it "won't compensate the User for funds or make repeated payouts under any circumstances".
• Clause 4.24.5: "Any subsequent statements by the User that the funds were in fact not received, made after they provided confirmation, won't be accepted for consideration".

A polite "yes, everything arrived, thanks" in the chat — and the case is closed forever. Even if the bank later debits the money, reverses the payment or blocks the card. Formally, this is the service's protection against bad-faith claims, and that logic has grounds. But the practical consequence for the client is very broad: a confirmation counts as just pressing a button, a screenshot, or a message. If you have even the slightest doubt that the transfer will go through smoothly, you clearly shouldn't rush into such a confirmation.

Refunds

• Clause 4.13: if the payout isn't sent within 24 hours of the payment being received, "the User may demand termination of the agreement by canceling their request and returning the electronic units in full".
• Clause 4.15: refund — within 72 hours.
• Clause 10.1: "Refunds are possible exclusively at the discretion of the Service".

A direct contradiction. In section 4 the user has the right to demand a refund; in section 10 that right turns into "however the Service decides". Figuring out which clause applies will probably have to happen in correspondence.

• Clause 4.23.3: "Payment details for requests are valid for 60 minutes; after that time, transfers aren't counted and are non-refundable".
• Clause 4.11: "In case of termination of the agreement, Electronic units received after the above deadline are subject to return to the sender's details" (minus fees).

Another contradiction. One clause says "we'll refund minus fees", the other — "non-refundable". This is about a scenario that happens all the time: someone paid for a request a few minutes late. Which of the two clauses kicks in depends on which one the service picks — and that's essentially the right to decide the fate of someone else's money at its own discretion.

• Clause 4.23.4: "Transfers to the Service's details without creating an exchange request aren't counted as payment and are non-refundable".

If you get the request details wrong or send money outside the process — by the letter of the rules, the money doesn't have to be returned. Plus clause 9.8: the service isn't responsible for funds transferred to a blocked card, or for a card being blocked after the transfer.

• Clause 4.23.2: if the agreement is terminated unilaterally, the refund is made "within 60 calendar days".

Meanwhile, clauses 4.15 and 10.5 mention 72 hours. Three different refund timelines in one document.

• Clauses 4.23 and 4.23.1: the service may terminate the agreement if the client "violated the procedure for using the Service" and "the presence of signs of violation in the client's actions… is determined at the discretion of the Service".

The criterion is entirely on the service's side.

• Clauses 4.19 and 4.20: the service may refuse further service and "all subsequent Requests created by the User after the refusal… are automatically frozen".

In other words, funds from new requests may end up frozen simply because the service previously decided not to serve you anymore.

• Clause 4.17: the service may cancel an ongoing operation and return the funds "without explanation". Plus clause 4.5: the right to refuse an exchange unilaterally.

Rates and fees

Promo materials (Bits.media, MMGP): "No hidden fees or unpleasant surprises — the rate is always transparent and fair", "Instant exchanges in 30–60 seconds".

• Clause 4.7.1: the payout amount is fixed, "unless the rate on the Binance exchange has changed by 0.1% or more from the moment the request was created until the funds were credited".

0.1% is a very narrow threshold. On a volatile market, the Binance rate crosses that mark regularly, which means the "fixation" in practice almost never works. It's not the same as a "hidden fee", but the promise of "transparency" and the actual mechanics diverge noticeably.

• Clauses 4.8 and 5.3: "When creating a request on the Site, the rate and cost of services are for informational purposes only".
• Clause 8.3: if a request is paid later than the allotted time, the service "reserves the right… to recalculate at its own discretion".
• Clause 8.4: if the request's rate doesn't match the market rate (including due to a website malfunction), the service may "recalculate the request at the current rate or issue a refund". Clause 9.5 — three more grounds for recalculation.

All in all, the quoted rate is informational, and recalculation is the service's unilateral right. It's a common industry construct, but it doesn't sit well with the advertising claim that "the rate is always transparent and fair".

• Clauses 4.6 and 5.1: rates are changed by management "without additional notice".
• Clauses 4.7 and 5.2: the service isn't responsible "for the User's expectations regarding changes in tariff plans".
• Clause 9.2: the minimum amount varies by direction and "the User clarifies the information with the operator".

Minimums aren't published, meaning until you talk to an operator you don't know whether your amount will fly. And clause 4.12 allows the service, if there's a discrepancy in the amount, to terminate the agreement unilaterally and refund the funds minus fees within 72 hours.

• Clause 4.21: in Qiwi, YooMoney, Perfect Money, Payeer, a transfer can be frozen for up to 48 business hours.
• Clause 4.23.5: with a heavily loaded Bitcoin network, processing can stretch up to 48 hours.
• Clause 9.4: semi-automatic requests — up to 12 hours, manual ones — up to 36 hours.

"30–60 seconds" from the ads and "up to 36–48 hours" from the rules are, to put it mildly, two different pictures. Formally, one is about the auto pipeline, the other about exceptions, but the stated spread is worth keeping in mind.

AML policy

To be fair: the service's AML section is better developed than many. There's a measurable scale, a list of blocked categories, a described procedure.

• Clauses 2.1–2.3: all assets go through an automatic AML check via "licensed analytical services"; the acceptable risk limit is no more than 70%.
• Clause 2.4: regardless of the overall percentage, transactions connected to darknet, scam/fraud, illegal service, stolen coins, sanctions (OFAC, EU, FATF), mixers, ransomware and terrorism financing are automatically blocked.
• Clauses 3.1–3.3: 0–50% — low risk, standard exchange; above 50% up to 70% — medium, the service may ask for information about the source of funds and/or KYC; above 70% — high, the payout is suspended, full verification is needed for a refund, and the refund fee is 10%.
• Clauses 4.1–4.2: transfers from sanctioned addresses and platforms aren't accepted, including Garantex, Bitzlato, Tornado Cash, Hydra and other mixers and darknet marketplaces; such funds "are subject to freezing pending clarification of the circumstances", with the freeze lasting up to 180 calendar days.
• Clauses 6.2–6.4: with suspicious assets, the payout may be suspended for up to 180 days, funds held, an internal investigation conducted; after successful verification, the refund takes up to 72 hours, minus the network fee and the service's costs.

The 70% threshold is quite lenient by industry standards (some exchangers cut off at 60% and below), and that's rather a plus for the user. But the flip side is up to 180 days of freezing and a 10% fee on refunds for high-risk transactions.

AML policy, clause 8.1 and the agreement, clause 4.18: the sender and the recipient must be the same person; transfers in favor of third parties are prohibited. Meanwhile, the service advertises PayPal, Revolut, SEPA Instant directions and Latin America routes — that is, scenarios that very often involve paying for third parties or using someone else's details. The rule is formally understandable (the fight against drop-accounts), but users should understand: exchanging "for a friend" or "for a client" is formally prohibited and is grounds for refusal.

Other little things

Clause 4.3: "Questions and claims regarding requests are accepted within 24 hours from the moment the request is created." Against clause 10.4: refund requests are considered "within 7 business days". You have to report a problem almost immediately, while the service can take over a week to consider it. The asymmetry clearly doesn't favor the client.

Clause 4.24.2 effectively turns any confirmation into a waiver of claims — and that combines with the 24-hour window in clause 4.3. Two mechanisms working in the same direction.

Site footer: "© 2016-2026" on a domain registered on 06/25/2026. Looks like a default copyright line from a script template. Not a crime in itself.

In the headlines on Bits.media and MMGP the service is called "BestPay24"; the domain and brand are "BeastPay24." A small thing, but for a financial service it's a sign of sloppiness in communication.

The /reviews page on the site itself contains exactly one review, dated 06/25/2026 — that is, the domain registration date. It's most likely a test or demo entry, but it looks like a customer review. It should be seen as window dressing, not proof of operation.

The Monik monitor shows "Age: 1 year", whereas the domain is about four months old. The explanation: a discrepancy in the monitor's data, not necessarily in the service's data, but when assessing age it's better to rely on WHOIS.

The AML checker is a separate paid product (10 checks for $5, 20 for $9, 50 for $20). The page features a "Check history" with sample addresses and scores (5%, 59%, 92%). It looks like demo data rather than a real client history. Selling AML checks is a legitimate business in itself, but monetizing AML inside an exchanger looks like mixing the roles of the screener and the interested party.

Verdict

BeastPay24 is a service with a tidy exterior and a very short real history. It does have documents, and in places they're better than average: the AML policy contains a clear risk scale with specific thresholds, a list of blocked categories, a described procedure and an understandable list of documents. The contacts page spells out anti-phishing rules that are genuinely worth following. But that's exactly where the main problems are concentrated: the confirmation of receipt of funds that closes the case forever (clause 4.24), non-refundable transfers that arrive after the 60-minute window or without a request at all (clauses 4.23.3–4.23.4), the contradiction between the right to demand a refund (clause 4.13) and "refunds exclusively at the discretion of the Service" (clause 10.1), three different refund timelines in one document, and the claim that "transactions don't require mandatory verification" alongside mandatory full KYC to recover funds that failed AML. Plus the age — four months, no legal entity, no applicable law. There's no proof of fraud, but there's no proof of reliability either — just promises and an off-the-shelf template.