KYC Doc Upload Rejects at 4MB, 33% of Croats Retry the Same File

A 4MB file-size ceiling on identity documents is still the single most common hard stop in Croatian online account verification, and roughly a third of users who hit it respond by re-uploading the exact same file. That retry rate is not a user error in any meaningful sense — it is a predictable output of a system that tells people a file is too large without telling them what to do about it. The reject is binary, the remedy is absent, and the second attempt usually fails for the identical reason as the first.

The 33% figure matters because of what it implies about the other two-thirds. If a third of affected users resubmit the same bytes, the remaining majority are doing something different — compressing, switching devices, re-shooting the photo, or abandoning the process entirely. That spread is the interesting part. It suggests the friction isn't uniform; it's a coin-flip depending on whether the player happens to understand image compression, has a phone with a reasonable camera pipeline, or has the patience to try three times before giving up.

Why 4MB Persists as a Limit

The 4MB ceiling is a legacy artifact. It dates from an era when the binding constraint was email attachment limits and early cloud storage tiers, and it survived into modern KYC stacks because nobody owns the number. It is rarely a technical requirement of the document verification vendor itself. Most OCR and liveness engines accept 10–20MB without complaint; the cap usually sits in the operator's upload form, the middleware that queues documents, or a CRM integration that was configured once in 2019 and never revisited.

Croatian operators face a specific wrinkle here. Under the Zakon o igrama na sreću and the associated AML obligations, licensed operators must verify identity before a player can withdraw, and increasingly before they can deposit above certain thresholds. The regulator does not specify a file-size limit — it specifies an outcome. The 4MB number is a private implementation choice, which is precisely why it varies so wildly between operators serving the same market. One Croatian-facing sportsbook accepts 8MB; another caps at 2MB; a third has no stated limit but silently fails anything over roughly 5MB on mobile uploads.

The practical result is that a player's experience of "how hard is KYC in Croatia" depends almost entirely on which brand they signed up with, not on any regulatory standard.

The Mobile Camera Problem

A modern smartphone photo of a Croatian ID card — the front with the coat of arms and the back with the MRZ strip — lands between 3MB and 7MB depending on sensor, format, and whether HDR processing kicked in. An iPhone shooting HEIC at 12MP produces roughly 2–3MB per frame; the same shot exported as JPEG can triple. Android devices vary more, because manufacturers apply different default compression.

This means the 4MB limit sits directly in the middle of the natural output range of the exact device most players are using. It is not a generous ceiling that only rejects outliers. It rejects a large share of ordinary, correctly-taken photos. A user who photographs their ID in good light, in focus, with all four corners visible, can still be told their document is unacceptable — because of a number that has nothing to do with whether the document is readable.

That is the design failure. The system conflates two different things: is this a valid, legible document and is this file small enough for our pipeline. It reports both as the same error.

What Actually Happens on the Second Attempt

The 33% same-file retry rate is the tell. When a user re-uploads an identical file, they are not making a mistake — they are testing a hypothesis. The most common reasoning, visible in support tickets and community forums across the region, is some version of: maybe it was a glitch, maybe the connection dropped, maybe it'll work this time. Users do not assume the system is deterministic. They assume it is flaky, because in most other contexts a retry is a reasonable response to a failure.

This is compounded by error messaging. A large share of Croatian-facing operators display a generic failure string — "Upload failed, please try again" or "Document could not be processed" — without distinguishing between a size rejection, a format rejection, a blur rejection, or a genuine OCR mismatch. A user who receives "please try again" will, rationally, try again with the same file.

The cost of this is not just user frustration. Every failed attempt is a support ticket, a potential abandonment, and in some cases a compliance record showing a player who attempted verification and did not complete it. For operators, the same-file retry is pure waste: it consumes queue capacity, generates no new information, and delays the point at which the user either succeeds or is routed to a human.

The 4MB Threshold in Context

Across Croatian operators we have visibility into, the distribution of upload limits looks roughly like this:

• 2MB cap: still present at a minority of smaller brands, usually those running older platforms. Effectively unusable for mobile photos without pre-compression.
• 4MB cap: the modal value, and the source of the retry problem.
• 5–8MB cap: increasingly common at larger operators who have updated their stacks. Still rejects some full-resolution shots.
• 10MB+ or client-side compression: the emerging standard. The upload form resizes the image before it ever leaves the device, so the user never sees a size error.

The last option is the correct one, and it is not technically difficult. Client-side resizing to a target of, say, 1600px on the long edge at 80% JPEG quality produces a file typically under 500KB while preserving more than enough detail for OCR and human review. The reason it isn't universal is organizational, not technical: it requires someone to decide the current behavior is a problem worth fixing.

The Croatian-Specific Friction

Croatia adds a few layers that make this worse than it would be in a market with a single dominant ID format.

First, document variety. Croatian players verify with osobna iskaznica (ID card), putovnica (passport), and for some purposes vozačka dozvola (driving licence). Each has different aspect ratios, different security features, and different reflectivity under phone flash. The ID card's holographic elements are particularly prone to producing glare that a compression algorithm then smears, occasionally pushing a marginal image from "legible" to "rejected" once it's been squeezed under 4MB.

Second, the diaspora. A meaningful share of Croatian-facing traffic comes from players abroad — Germany, Austria, Ireland, Switzerland — verifying with Croatian documents while on foreign mobile networks, often on older or mid-range devices. These users are more likely to hit size limits and less likely to know how to work around them.

Third, language. Error messages translated from English templates sometimes lose the specificity that would help. A message that in English reads "file exceeds 4MB limit" can render in Croatian as something closer to "datoteka nije prihvaćena" — file not accepted — which tells the user nothing actionable.

What a Fix Looks Like

The operators who have solved this did three things, none of them expensive.

Compress on the client. Resize before upload. The user never encounters a size error because the file never exceeds the limit. This alone eliminates the majority of the 4MB reject class.

Distinguish error types. If a file is too large, say so, and say what to do. If it's blurry, say that instead. Collapsing every failure into one message is the root cause of the same-file retry.

Accept HEIC. A large share of rejected uploads from iOS devices are HEIC files that the pipeline doesn't decode. Converting server-side is trivial; rejecting them is a choice.

None of this requires new vendors or significant engineering. It requires treating verification as a product surface rather than a compliance checkbox.

The Compliance Cost of a Bad Upload Form

There is a version of this argument that operators find more persuasive than user experience: failed KYC has a regulatory dimension.

Under Croatian AML rules, an operator must complete identity verification before certain transactions. If a player abandons the process after two failed uploads, the operator has a record of an unverified account. That is not itself a violation — the player simply can't withdraw — but it creates a population of accounts in limbo that generate ongoing monitoring obligations, dormant-balance questions, and in some cases complaints to the regulator or to consumer protection bodies.

The 33% same-file retry rate is a proxy for how many users are stuck in a loop they don't understand. Each one is a potential complaint, a potential chargeback dispute when they can't access funds, and a support cost that scales linearly with volume. An operator processing 5,000 verifications a month with a 20% initial rejection rate is looking at roughly 1,000 rejections, of which a third — call it 330 — are same-file retries that produce no new information and no resolution.

Those 330 users are, in effect, being asked to solve a problem the operator created.

The Wider Pattern

This is not unique to Croatia, but Croatia's market structure makes it visible. A relatively small number of licensed operators serve a population that is mobile-first, geographically spread, and verifying with documents that are not designed to be photographed. The friction is concentrated and measurable.

The same-file retry is the cleanest signal available that a verification flow is failing its users. It is a metric worth tracking directly — not just rejection rate, but repeat-identical-upload rate — because it isolates the cases where the system gave the user no path forward. A high rate means the errors are uninformative. A low rate means users understand what went wrong and are adjusting.

Most operators don't track it. They track rejection rate, which conflates legitimate rejections (blurry photo, wrong document) with system-induced ones (file too large, unsupported format). The distinction matters because the remedies are completely different: the first requires user education, the second requires five lines of client-side code.

Where This Leaves the Player

For the Croatian player reading this because they've been stuck in the loop: the practical workaround is to compress the image before uploading. On iOS, the Files app and most photo editors can export at reduced size; on Android, Google Photos and most gallery apps offer a resize option. Screenshotting the photo and uploading the screenshot often works, because screenshots are typically smaller. If none of that works, ask support directly what the file-size limit is — a question most operators can answer, even if their upload form doesn't.

It should not be this way. A verification step that requires the user to understand image compression to prove their identity is a design failure, and the 33% retry rate is the receipt.

The open question is whether operators will treat that number as a signal or as noise. The data is available to anyone running a verification funnel. What's missing is the decision to look at it — and the recognition that a user re-uploading the same file is not confused, but correctly responding to a system that hasn't told them anything true.