<- Tom Shachar

AI document intelligence for a financial-services firm

The documents arrive already filed. That is two days a week I am not spending chasing clients for them, and I handled more cases this month than ever.”- the firm's operations coordinator
A WhatsApp-to-CRM pipeline that identifies, names, and files Hebrew KYC documents automatically, and chases the missing ones, running in production at ~$0.005 per document with full failure observability.

Anonymized case study. The firm is an Israeli financing-advisory practice; client data, document contents, and the codebase are kept private. Everything below is architecture, AI approach, economics, and outcomes.

Problem

The firm collects KYC documents from every client over WhatsApp - national ID, driver's licence, bank statements, account confirmations. Each arrives as an unlabelled Hebrew photo or PDF, often six or more at once. Staff had to recognise each one, name it, file it against the right client, then chase whatever was still missing. Slow, error-prone, and it did not scale.

Why AI

Rule-based parsing cannot read a creased photo of a Hebrew bank letter, tell a driver's licence from a vehicle licence, or map free-text Hebrew onto a checklist where every advisor phrases the items differently. That is classification over noisy real-world input - exactly where a vision-capable model earns its place and a deterministic system would be brittle.

Architecture, and the three rules behind it

It is a parallel listener, not a bot in the funnel. The app receives its own copy of every inbound message alongside the firm's existing chatbot, which is never touched. Each document is its own event, so a burst cannot be dropped.

Three rules do the real work:

The model decision

I benchmarked the cheaper model at roughly 50% accuracy on real Israeli documents against 100% for the stronger one, and deliberately kept the expensive one. At about $0.0053 a document, accuracy wins and the argument is over. Certified live on the firm's real client files, with automated tests green before every deploy.

The failure that taught me the most

Three of four documents filed with a blank type and no confidence score. It looked like the model failing on easy documents. It was not a model problem at all: measured latency was creeping just past the timeout, so half the calls were aborted mid-flight and returned a silent null - and every error path was swallowing its own reason.

The insight I keep: blank is not wrong. A genuine misidentification still carries a label. Blank means the call never came back. The fix was a realistic timeout, a retry on the errors worth retrying and never on the one that would blow the delivery deadline, and structured observability everywhere - plus a dashboard that flags any filed-but-unidentified document, so a failure can never hide again.

Outcome

Live in production. Every incoming document is identified, named, matched to the client's checklist and filed with zero manual work, the firm's existing funnel entirely intact, at about half a cent per document.