The Checker You Pay For

Introduction

Fraud against spend-management platforms is usually pictured as theft from the platform itself: a stolen card is spent, a false reimbursement is paid, a chargeback is booked. This blog documents a quieter pattern, observed in a recent case within the environment of a Group-IB Fraud Protection client, in which the platform was not the target of the fraud, but was instead abused as a component of the fraud’s infrastructure.

Two linked behaviours were observed. In the first, the platform’s trusted email and payment rails were used to lend credibility to phishing scams aimed at people who are not the platform’s customers. In the second, the platform’s bank-account linking flow–provided through an open-banking aggregator–was used to validate stolen card and bank credentials, a checking function that fraudsters abused at no cost to themselves.

In neither case does the resulting loss appear on the platform’s profit-and-loss statement. It is felt instead as reputational harm, as a cost carried on the aggregator invoice, and as compliance exposure. Because most anti-fraud programmes are built to detect loss to the institution at the point of transaction, this activity can proceed largely unobserved. That is the visibility gap being exploited.

A second gap is now opening alongside it. Across several jurisdictions, regulation is moving from a position where the victim bears the loss, towards one where the organisations whose services enabled a scam may be held accountable, even when they did not lose money and the victim was never their customer. The fraud a platform cannot see is becoming the fraud it may be answerable for. This blog details the scheme, the impact across credibility, cost and compliance, and the detection approach that allows this activity to be identified at the point of onboarding.

Key Discoveries

• A scam-as-a-service operation abused a legitimate spend-management platform as fraud infrastructure, using it to deliver phishing and to test stolen credentials, rather than attacking the platform directly.
• The platform’s own payment-notification and email rails were used to deliver Poshmark-impersonation phishing, lending the messages the credibility of a trusted payment brand.
• The platform’s open-banking account-linking flow was abused as a checker to confirm that stolen card and bank credentials were live and funded, with the per-link verification cost borne unknowingly by the platform.
• The harm is externalised off the platform’s profit-and-loss statement, appearing instead as reputational damage, aggregator-invoice cost and growing regulatory exposure, which is why loss-based controls tend to miss it.
• The activity is detectable before any money moves, at account creation, first outbound message and first account or card link; onboarding-stage detection reduced the time to block from hours to under a minute.
• Group-IB Fraud Protection stopped more than 230 fraudulent accounts in May 2026.

Who may find this blog interesting

• Fraud-prevention and anti-fraud operations teams
• Risk and compliance officers at fintech, spend-management and banking institutions
• Trust and safety and product-security teams at platform businesses
• Threat intelligence specialists
• Computer Emergency Response Teams (CERT)
• Cyber investigators and law enforcement
• Finance and risk leaders (CFO, CRO)

Group-IB Fraud Intelligence Portal

Group-IB customers can access our Fraud Intelligence portal for more information about the scam scheme referenced in this blog.

The Fraud Scheme

The abuse resolves into two linked layers. In the first, the platform is used to deliver phishing. In the second, the platform is used to test the credentials that phishing collects.

Phishing that borrows a platform’s credibility

At the end of April 2026, a Group-IB Fraud Protection client reported that its payment-notification and email systems were being abused to distribute phishing links to thousands of recipients each day. Working with Group-IB CERT and the Investigation team, fraud analysts assessed the activity as consistent with the work of a well-documented scam-as-a-service operation (i.e. Classiscam), in which operators use Telegram bots to generate fake phishing pages and to harvest payment data from the users of online marketplaces.

What distinguishes this scheme from a conventional phishing campaign is the delivery method. The operators do not send the phishing emails themselves. Instead, a legitimate business platform is exploited as a middle layer. A victim’s email address is added inside the platform, and the platform’s own notification system then delivers the fraudster’s message impersonating an online marketplace and claiming that a buyer had paid for an item.

Fig 1 below shows a mock-up of one such message, recreated from the original. The lure arrived as a “paid” expense notification from the online marketplace Poshmark, telling the recipient that a sale is on hold until they complete an identity check through a shortened link. Note that Poshmark was also a victim of impersonation and was not involved in, nor was its systems compromised by this activity.

Figure 1. Mock-up of a phishing message delivered through the platform’s own notification system, impersonating Poshmark and carrying a shortened phishing link.

Two advantages are gained by routing the message this way. First, the notification is generated by a legitimate business, so it may be less likely to be filtered as spam. Second, the platform’s brand becomes part of the lure. Because the platform provides genuine payment services, a message that appears to come from it carries an implicit assurance that a payment has been made and is waiting to be collected. A person who would ignore an unsolicited link from an unknown sender may act on the same link when it arrives from within a trusted payment brand.

In the early stage of the observed phishing campaign, large numbers of disposable email addresses were used to create many accounts from one or a small number of devices (Fig 2). Once it became clear for fraudsters that multiple accounts on a single device were being blocked, their tactic was adjusted quickly to one account per device.

Figure 2. Multiple accounts created from a small number of devices using disposable email addresses. The pattern is consistent with automated account creation rather than genuine onboarding.

That adjustment did not defeat detection in this case. The same device fingerprint and geo-fingerprint were present behind the newly separated identities, which indicated that a single physical device sat behind them (Fig 3). The additional newly created device identities were assessed to be the product of deliberate manipulation, such as clearing cookies or using private browsing.

Figure 3. Device-intelligence view. A shared device fingerprint and geo-fingerprint reveal a single physical device behind several virtual device identities.

A recipient who followed the link would then be taken to a phishing page that impersonated Poshmark’s brand identity and displayed a countdown timer, urging completion of an account-verification step before the funds could be released (Fig 4). The page presented a form designed to collect personal and payment data, including name, card details, phone number, email address, billing address, one-time passcode, and card balance, and in some cases access to a payment wallet or internet-banking details (Fig 5).

Figure 4. Phishing page impersonating Poshmark’s brand identity, using a countdown timer to pressure the recipient into completing an account verification step.

Figure 5. Phishing form used to collect personal and payment data, including card details, one-time passcode and card balance.

The checker layer that abuses the platform’s onboarding

Phishing is usually the opening stage of a fraud. Before stolen credentials can be monetised, they must be tested to confirm that they work. This checking step is traditionally carried out against the target bank. In this campaign, it was carried out against the spend-management platform’s own bank-account linking flow, which provides a similar confirmation signal, often with less scrutiny, lower visibility and generally weaker defences than a bank’s own channel.

To receive funds, a user may connect a personal bank account. In many markets, the platform offers two ways to do so. A login-based path, brokered by an open-banking aggregator, returns live balances and transaction history. A manual path captures only static routing and account numbers and returns nothing about the state of the account. For a checking operation, the login-based path is the more valuable of the two, because it confirms not only that a credential is valid but that the account behind it is live and funded, which is precisely the output a checker exists to produce (Fig 6).

Figure 6. The login-based path, brokered by an aggregator, returns live balance and transaction data.

The checking step was observed running alongside the phishing activity in real time, which allowed one-time passcodes captured from victims to be used immediately. The same devices were used for both halves of the operation.

One example demonstration:

• On 27 April, device identity [496-] was associated with two accounts created to send payment confirmations carrying phishing links and two accounts created to test cards.
• On 28 April, device identity [524-] was associated with six accounts of each kind (Fig 7)

As before, a shared device fingerprint and geo-fingerprint indicated a single physical device behind the separate device identities. And once device identity [524-] appeared, device identity [496-] was not observed again.

Figure 7. Linked device identities [496-] and [524-], each used both to send phishing invitations and to add stolen cards for testing, on 27 and 28 April respectively.

The same detection evasion mindset was visible elsewhere in the campaign. Disposable email addresses were used throughout, and network anonymisation was extensive, including hosting services, mixed IP classes, VPNs, data-centre ranges, proxies and residential IP addresses, all used to defeat rate limits (Fig 8). Blocking by IP address or rate-limiting alone would have had limited effect against this activity.

Figure 8. Network anonymisation observed in the campaign, including hosting services, mixed IP classes, VPNs, data-centre ranges and proxies used to defeat rate limits.

The Platform is the Tool, Not the Target

Most fraud controls rest on a single assumption, that fraud will show up as a loss to the institution being defended. Cards are watched for unauthorised spend, reimbursements for false claims, and accounts for takeover. The controls watch the ledger, and they act when the ledger moves.

The pattern described here does not move that ledger. The platform is not robbed. It is borrowed. A legitimate service, trusted email and payment rails on one side and frictionless bank-account linking on the other, is turned into working infrastructure for a fraud operation whose victims and losses sit almost entirely outside the platform’s own books.

This is the visibility gap at the centre of this research. When a platform is used as a tool rather than attacked as a target, the harm is externalised: to marketplace sellers and cardholders who are not its customers, to its own vendor invoice, and to its compliance posture. None of these impact the profit-and-loss statement that a fraud team watches, so a programme built to detect loss to the institution can miss the activity altogether.

The environments in which this occurs tend to share two features, a straightforward onboarding process and  instant provisioning of aggregator services at no cost to the end user. Both are legitimate, and for genuine users both are desirable, since they reduce friction and speed up sign-up. The same properties also lower the cost of operating at scale for a fraudster. The point here is not to criticise a particular product design. It is that the pattern is likely to recur wherever those two features are combined, and to become more common as open banking spreads and as stronger anti-fraud controls in the banking sector push checking activity towards third-party platforms elsewhere. The detection philosophy that surrounds these environments needs to be updated for a world in which these very third-party platforms are in turn abused to become the instrument of a fraud rather than its target.

The Impact

1. Credibility

The first harm is reputational, and it is borne entirely outside the platform. The victims are typically sellers on an impersonated marketplace, who may not even be users of the platform. The platform typically has no contact with the genuine seller, who deals only with the marketplace, so the platform has no visibility into the victim at all. Its brand is used to defraud people who never chose to interact with it, and the damage to trust accrues regardless.

2. Financial

The second harm is financial, and it is carried on the aggregator invoice rather than the fraud ledger. Where a platform pays the aggregator for a per-verification (pay-as-you-go) fee model, or through tiered monthly subscription plans with included volume caps, the validation that the checker requires is performed at the platform’s expense.

The direct cost may be modest, and that is part of why it goes unnoticed. Based on Group-IB estimates, open-banking account verification is commonly billed at roughly USD 0.30 to 1.00 for each successful connection. For a platform that records one million successful, billable links in a year, and on the assumption that between 0.5 and 1 per cent of those links are checker activity, the illustrative cost is as follows.

Read on its own, two to five thousand dollars is immaterial, and it sits comfortably below the level at which a vendor invoice is questioned. The significance is not the size of the number. It is that the platform may be unknowingly, bearing the cost of the checking layer of a fraud operation. That fact carries the third harm.

3. Legal and regulatory

The third harm is the accountability exposure, and it is the one most likely to grow. Where its services are misused in this way, the platform may, without its knowledge, be drawn into a fraud operation directed at the customers of other institutions. A growing number of regulatory regimes place scam-prevention duties on firms whose services are used to facilitate scams. A similar direction of travel can be seen in several jurisdictions. In Australia, the Scams Prevention Framework, enacted  in 2025, will impose enforceable duties to prevent, detect and disrupt scams on designated sectors, such as banks, telecommunications providers and certain  digital platforms, with civil penalties reaching AUD 50 million for the most serious contraventions, and it can be extended to further sectors. In the United States, Nacha’s 2026 risk-management amendments require participants across the ACH network, including non-bank third parties, to monitor for fraud, including payments authorised under false pretences (a category that covers many impersonation scams). In the United Kingdom, mandatory reimbursement rules that took effect in 2024 generally split the cost of reimbursing the victims of authorised push-payment scams between the sending and the receiving provider.

None of the above frameworks name a spend-management platform today. However, what they share is a spreading principle: firms whose services are used to carry out the scam may be expected to share responsibility for preventing it, not just the firms whose customers were the direct victims of financial loss. A platform used as infrastructure may in time be affected by this principle. A prudent assumption is that the question may reach it in time, and that it should be ready to show it could see the activity and stop it.

This is where the financial and legal harms meet. The same link that quietly adds a line to the aggregator invoice is also the point at which the platform services may be drawn into another party’s fraud. Whether user experience and fraud exposure can be balanced well enough to reduce the exposure is an open question for every platform that may be used as a tool rather than attacked as a target.

Detection: Three Chances Before the Platform is  Abused

The reassuring finding from this research is that activity which may be invisible to loss-based controls can be detected  at the point of onboarding. In the case described above, detection can be built around three points where the abuse touches the platform, and each point is a chance to stop it.

The first chance is the account, when it is created. A disposable email, a device and geo-fingerprint already seen on other accounts, and the machine-like rhythm of an automated sign-up can flag an account as likely fraudulent  before it does anything. An account blocked at this point cannot then be used to send  phishing messages or test cards.

The second chance is the message, when a young account first reaches an outside recipient. A brand-new account that emails a stranger, invites many recipients in quick succession, or repeats the same message is already behaving unlike a real user. That behaviour is visible on its own, and it is stronger still when the link the message carries is checked against phishing and domain intelligence at the same moment.

The third chance is the link, when an account adds a bank account or a card. A card added minutes after sign-up, a run of link attempts from one device, or a linked account that shows no other genuine use are the marks of testing rather than real onboarding.

The same handful of signals runs across all three points: device, behaviour, email, network and graph. Graph analysis matters most, because it connects everything. It was graph analysis that tied the phishing accounts and the card-testing accounts on devices [496-] and [524-] to the same hand behind them, and turned two separate nuisances into one recognised operation.

Conclusion

This fraud scheme is so quiet by design, that a defence that looks only for its own losses is unlikely to see it. And yet the same fraud, invisible in the ledger, can be plain to see when defenders know where to look. The lesson is not to watch the transaction harder. It is to watch the steps that come before it, because it’s in this pattern that the fraud can be identified early on to reduce its opportunity for harm.

Since the Group-IB Fraud Protection team became involved in investigating this campaign, the time-to-block of a fraudulent account was reduced from several hours to under a minute, with an automated block applied at onboarding. In May 2026 alone, more than 230 accounts assessed as fraudulent were stopped before they could abuse the service. In this deployment, the onboarding logic operated at a level of precision assessed by Group-IB to be high enough to allow an automatic block rather than a referral for manual review.

This is where fraud work and compliance meet. Regulators are starting to ask platforms to prevent, detect and disrupt scams. And as such, the fraud that a platform cannot see, may increasingly become the fraud it is expected to be accountable for. The three detection points highlighted above, all of them before any money moves, are where a platform that is being abused as infrastructure can take actionable steps to do so, and evidence the steps it has taken.

Recommendations

For fraud and security teams: Treat the actions that precede a payment as first-class signals. Watch the three points where this abuse shows itself, the new account, its first messages, and its first bank or card link, using the device, behaviour, email and graph signals that reveal them. The setup is the fraud, and it is visible while transaction monitoring is still waiting for a transaction that never comes.

Harden the messaging surface: A new account that can message the outside world at will is a gift to a phishing operation. Rate-limit or reputation-gate outbound messages from young accounts, and scan the links they carry against phishing and domain intelligence before the message leaves the platform.

Harden the linking surface: Account linking is where the checker does its work, so it deserves friction the moment an account looks untrusted. Add a step-up check for links from new or low-trust accounts, and cap the number of link attempts allowed from a single device.

For finance and risk teams: Look for this fraud where it actually lands, on the aggregator invoice. The number of account links, and any volume that runs ahead of real demand, is a fraud signal as much as a cost line.

For compliance and legal teams: Assume the direction of regulation rather than wait for it. The duty to prevent, detect and disrupt scams is being introduced  in several markets, and detection before the payment is a practical way both to meet such duties  and to evidence the steps taken .

For the wider industry: Read this as a pattern, not one company’s problem. Any service that pairs easy sign-up with free account-linking could  be misused the same way, and more of them are being built every year.

Group-IB Fraud Matrix

Disclaimer:

Third-party trademarks. All product names, logos and brands referenced in this publication are the property of their respective owners. They are used solely for identification and descriptive purposes in the context of security research, and their use does not imply any affiliation with, or endorsement by, their owners. Screenshots of fraudulent resources are reproduced to document the impersonation of legitimate brands and services; the brands depicted are victims of that impersonation.

Third-party service providers. Certain screenshots and  references depict lawful hosting, serverless and API providers whose services were abused by the operators without their knowledge or involvement. No wrongdoing on their part is alleged or implied.

No legal advice. This publication is provided for information and defensive purposes only and does not constitute legal advice. Statements concerning the possible legal position of any party are general in nature; readers should obtain advice from a qualified adviser in the relevant jurisdiction.

Assessments and attribution. All assessments, attributions and confidence levels stated in this publication reflect the information available to Group-IB as at the date of publication and may change as further information becomes available. Where conduct is attributed to accounts, channels or groups, Group-IB makes no assertion as to the identity of any individual behind them beyond what is expressly stated.