High Five Studio

October 2026

KYC Doc Upload Resumes at 72%, 29% Resubmit the Same ID

KYC completion has settled at 72%, but the stranger figure is the 29% who resubmit the exact same ID file, revealing where verification queues really stall

KYC Doc Upload Resumes at 72%, 29% Resubmit the Same ID

Verification queues across Croatian-facing operators have settled into a pattern that nobody planned for: document upload completion has stabilised at roughly 72% of players who start a KYC flow, and of the 28% who stall, close to 29% eventually resubmit the exact same file they uploaded the first time. The number is drawn from a six-month sample of onboarding events across a mid-sized set of EU-licensed brands taking Croatian traffic, and it holds within a couple of points whether you slice it by mobile or desktop. The interesting figure isn't the 72% — it's the 29%, because a same-file resubmission means the player did not understand, or was never told, what was wrong with the first attempt.

That single stat reframes how you should think about KYC. Most operators treat it as a compliance cost centre with a pass/fail gate. The 29% same-file resubmission rate says it is actually a communication problem that happens to have a legal deadline attached, and that the cheapest fix is usually copy, not engineering.

What the 72% completion figure actually measures

The headline number is easy to misread. A 72% "upload completion" rate is not the same as a 72% pass rate, and it isn't a 72% conversion rate either. It counts players who successfully attach at least one document to a KYC request after being prompted. What happens next — automated extraction, manual review, rejection, re-request — sits downstream and is where the real variance lives.

Where the drop-off happens

Across the sample, the 28% who never complete an upload split into three rough groups:

  • Abandonment at the document-type prompt (about 11 points). The player is asked for "a government-issued ID" and a proof of address in the same breath, sees two upload fields, and leaves. Croatian players frequently present a osobna iskaznica (ID card) and assume a bank statement is also mandatory when it isn't. Asking for one thing at a time lifts completion measurably.
  • Technical failure (about 9 points). File too large, HEIC format from an iPhone not accepted, camera permissions blocked in the browser. These are boring, fixable, and disproportionately affect mobile users, who make up the majority of Croatian traffic on the sportsbook side.
  • Deliberate stall (about 8 points). The player doesn't have the document to hand, is under 18 and realises it, or is waiting on a withdrawal that hasn't been requested yet. A request for KYC at registration catches a different population than a request triggered at first cash-out.

The distinction matters because the three groups need three different interventions. Better copy does nothing for a HEIC upload failure. A file-format fix does nothing for a player who simply doesn't want to verify yet.

The 29% resubmission figure is the diagnostic

If a player uploads, gets rejected, and then uploads the identical file, one of three things happened. Either the rejection reason never reached them, it reached them in language they didn't parse, or the reason given was wrong. In practice, the third is more common than operators like to admit — a blur-detection rule fires, the player is told "document unclear," and the document was in fact legible to a human reviewer.

A same-file resubmission is pure waste: it burns a manual review slot, adds a day to the player's cash-out, and increases the chance they contact support or leave. At 29% of stalled players, on a base where stalls are already 28% of starts, you're looking at roughly 8% of all KYC initiations producing a guaranteed-wasted review. For a brand processing a few thousand verifications a month, that is a meaningful chunk of a compliance team's day.

Why Croatian players stall in specific, predictable ways

Croatia's KYC friction has a local shape, and generic EU onboarding templates miss it.

Document types and the osobna iskaznica

The Croatian ID card is the default identity document, and it is well-suited to automated extraction — it carries a machine-readable zone and a clear photo. The problem is the address. A Croatian ID card shows an address, but many players have moved since it was issued, and proof of address is where the queue backs up. Operators that accept the ID card's printed address as sufficient for lower-tier verification, and only escalate to a utility bill above a withdrawal threshold, cut their proof-of-address requests substantially.

Watch the expiry date logic too. A card within 90 days of expiry is technically valid but a poor anchor for a long-lived account. Flagging it at upload — "this ID expires soon, you may be asked again" — is cheaper than a re-request three months later.

The mobile camera problem

Most Croatian sportsbook sign-ups happen on a phone, often over mobile data, often late. A KYC prompt that assumes a desktop scanner produces a predictable failure set: photos taken at an angle, glare from overhead lighting, the back of the card cropped because the player didn't realise both sides were needed. If your upload flow doesn't tell the player before they tap the camera that both sides are required, you have manufactured a resubmission.

A simple pre-capture screen — "you'll need the front and back, in good light, no flash" — is the single highest-leverage change most operators can make to the 29% figure. It costs a designer an afternoon.

Language and the OIB question

Croatian players are asked for an OIB (personal identification number) in some flows and not others, depending on the operator's licensing posture and payment rails. When the request appears without explanation, it reads as suspicious, and players stall. A one-line explanation of what the OIB is used for and that it is not shared with marketing removes a category of abandonment that no amount of engineering will touch.

The economics of a stalled verification

It's tempting to treat KYC friction as a compliance line item. It isn't. It sits directly on the deposit-to-withdrawal path, and the costs compound.

Take a player who deposits €50, runs it to €400, and requests a withdrawal. If verification stalls for 48 hours, three things happen. First, the player's expected value to you drops, because a meaningful share of players in a pending-withdrawal state will reverse part of the balance and play it back — which is revenue today and churn risk tomorrow. Second, support load rises: a stalled withdrawal generates a contact at a far higher rate than a completed one. Third, and least visible, the player's trust in the brand's payout reliability takes a hit that shows up in their next deposit decision, not this one.

The 72% completion figure is often quoted as if 100% were the target. It isn't, and shouldn't be. A verification flow that completes for everyone is a flow that isn't checking anything. The realistic target is to push completion into the high 80s while cutting the same-file resubmission rate — the 29% — toward single digits. The second number is the one that reflects whether your rejection messaging works.

The manual review queue as a leading indicator

If you want an early warning that KYC is degrading, watch the ratio of manual reviews to automated passes, and watch the share of manual reviews that end in approval on the first human look. A rising share of "approved after manual review, no change to document" means your automated rules are rejecting good documents. That is the same signal as the 29% resubmission rate, arriving a step earlier and cheaper.

What actually moves the numbers

The interventions that shift KYC completion and resubmission rates are unglamorous and mostly cheap. Ranked roughly by return:

  1. Tell the player the rejection reason in plain language, on the same screen as the re-upload button. Not in an email, not in a notification that gets buried. "The photo was too dark to read the expiry date — retake in daylight" converts; "document rejected" does not.
  2. Accept more file formats and auto-convert. HEIC, large JPEGs, and screenshots of PDFs should all be handled server-side rather than bounced back to the player.
  3. Ask for one document at a time. Sequential requests complete at a higher rate than a two-field form, even though they feel slower to design.
  4. Pre-capture guidance, per document type. Both sides, no flash, fill the frame. This is the fix that most directly attacks the same-file resubmission problem, because it prevents the bad first upload rather than diagnosing it.
  5. Tier the request. Ask for identity at registration or first deposit, and defer proof of address until a withdrawal threshold — a figure like €2,000 in cumulative withdrawals is a common and defensible line. Fewer requests, better-targeted ones.
  6. Show status. A player who can see "under review, typically 4 hours" waits; a player staring at a blank pending screen contacts support or leaves.

None of these require a new vendor. Several require someone to own the rejection copy, which in most operators is nobody's job.

Where responsible gambling fits

There's a reason KYC and safer-gambling checks share a queue, and it isn't bureaucratic convenience. Verification is the moment you learn who the player is, and it's the natural point to surface deposit limits, the Croatian institute for responsible gambling resources, and self-exclusion options — not as a legal footer, but as part of the same flow. A player who is stalling on KYC because they're uncomfortable with how much they've deposited is a player the flow should be able to catch. If your verification messaging is purely adversarial — "you must upload or you cannot withdraw" — you lose the chance to notice that. The 29% who resubmit the same file are often not confused about the document; they're confused about the process, and some of them are stressed about the money.

The open question: is 72% a floor or a symptom?

The completion figure has been stable enough across operators and quarters that it looks like a floor — as if roughly a quarter of players will always stall on document upload regardless of design. That reading is comfortable and probably wrong. The stability may simply reflect that most operators have converged on the same generic flow, so they produce the same generic failure rate. The 29% same-file resubmission rate is the tell: it varies far more between operators than the 72% does, which suggests the completion ceiling is a design choice rather than a hard limit.

The question worth putting to whoever owns onboarding at your operation is not "how do we get to 100%?" It's narrower and more useful: of the players who resubmit the same document, how many were told, in words they understood, why the first one failed? If the answer is "we send an email," you already know where the next few points of completion are hiding — and you know it without buying anything.