We’re stuck paying $0
Wait, are we really locked into Jumio forever just because it clocks in at six seconds while Veriff is... what, still "working on it"? The €0.60 average bleed per hit is nibbling straight off the NGR—what’s the playbook here when MGA starts breathing down necks for tighter blockchain monitoring?
Learn something new about this business every day.
Had Veriff ever struck me as a vendor who needed twelve months to decide whether to buy a bus ticket let alone spin up blockchain peers? I pushed them to 16 last March after our MGA renewal inspection threatened to park our Tier-1 licence in the sandpit until they could prove AML hits north of 99%. Now they nail ~99.8% in sandbox runs, but production latency still drifts between three and eight seconds depending on whether your MID is sitting in Luqa or Madrid DC. The edge isn’t the node count—it’s the peering table cache size and the fact they run a private IPFS subnet with MGA’s block-notifier service pre-loaded. For our volume (≈320k fresh KYC hits/year) the blended cost drops to ≈$0.45/check once you amortise the 16-node cluster over two years, yet the six-second promise never materialised; half the batches still land at 7.1s because their packet-inspection tier runs on shared Kubernetes. So we kept Jumio for the hot path, moved Veriff to overnight batch monitoring where real-time isn’t a licence requirement, and saved about €45k annually in rolling reserve rebates we’d otherwise lose on fraud-triggered chargebacks. The real trade-off is this: Jumio’s six-second claim evaporates when your user’s VPN is routed through Kazakhstan; Veriff’s accuracy evaporates when the Maltese regulator pushes another blockchain bulletin in the middle of the night and your batch queue backs up for three hours. Either way, MGA auditors will still ask for a reconciliation spreadsheet by 4 p.m., so pick your poison and build the contingency sheet first.
Do the math before you sign.
MID getting routed through Luqa vs Madrid DC—does that mean our servers’ physical location inside Malta affects KYC speed that much? 😅 So if we shift our whole stack to Marsaxlokk, do we finally crack the six-second mark, or is that just Veriff’s excuse to keep the wallet slightly fatter?
New to this, soaking it up.
yeah the whole Luqa vs Madrid DC bit isn't about magic coordinates on a map it's about where veriff's hardware sits relative to the internet's spine.
think of it like this: your user fires up the KYC page, veriff's little web widget curls round their ID and selfie, then that blob of pixels has to jump onto a tube that rattles through fibre-optic cable. if the tube’s exit door (the peering point) is in the same basement rack where veriff keeps their 16-node cluster, the trip’s one hop and done. if the blob instead gets routed north to madrid for an “arbitrage exchange” peering table somewhere in spain, every packet does a little tour of the continent before it even starts its crypto thing. packet latency isn’t some vendor boast—it’s physics plus who your ISP hands the traffic to at the border.
so shifting your stack to marsaxlokk won’t magically shrink the blob; it only helps if your datacentre is inside the same micro-gateway cluster that veriff uses for mlt-1, because then both halves of the handshake live on the same local exchange fabric. otherwise you’re still waiting for the blob to sail across the mediterranean. the real trick isn’t geography, it’s forcing the whole journey through the shortest possible plumbing.
Seen this movie before, operators.
isn't everyone pretending latency is the villain here while ignoring the elephant in the room – that Veriff's 99.8% sandbox accuracy still needs a layer of manual review when MGA drops another blockchain gazette overnight? seen this movie before, back in the Curacao days when we were all high-fiving ourselves over "real-time monitoring" until the regulator decided a pdf printout stapled to a palm tree in Willemstad counted as a blockchain alert. sure, their peering table cache shaves a few milliseconds, but have any of you actually read the MGA's circular 002/2023 update? because it just dropped another requirement that every flagged transaction needs a human sign-off within two hours or the licence gets parked, and that little detail turns Veriff's "99.8% accuracy" into a false economy when your chargeback team is suddenly working unpaid overtime at midnight.
and let's not pretend Jumio's six-second claim is anything more than marketing gas – switch on a VPN from Tbilisi and watch that number climb north of twelve seconds because, surprise surprise, their cloud stack still routes the packet through AWS us-east-1 like it's 2018. the vendor's latency slide deck always shows the lab version; production looks like a drunk pigeon hopping across a parking lot. ClassicGuy talks about dropping €45k annually by offloading to batch monitoring, but has anyone costed the rolling reserve hit when a sudden spike of Ukrainian shell-company deposits lands between midnight and 4am and your batch queue is still three hours behind? rolling reserve eats that €45k in about thirty minutes flat.
so the real question isn't whether Veriff or Jumio is faster today; it's which vendor's latency tailspin you can afford to ride when the MGA auditor slaps a spreadsheet on the table at 3:47pm and wants the reconciliation done by 4:00. pick the poison that doesn't bankrupt the affiliate payments next quarter, because afaik neither one of them has discovered perpetual motion yet. ah well, we'll see
Launched a few, lost money on more 😉
Jumio’s six-second pitch sounds lovely on their deck, but watch the VPN do its little magic trick and suddenly it’s closer to twelve. Meanwhile Veriff’s blockchain hustle drops the latency a hair, yet the manual review pile grows every time MGA sneezes out a new circular. So which slice of nightmare do we carve off—still haven’t worked out if the €45k annual saving outweighs the three-hour lag when the midnight batch queue explodes and the rolling reserve takes a throat punch. Anyone benchmarked their FTD uplift vs those chargeback spikes yet?
New to this, soaking it up.