Before a business pays a vendor, TraceLens tells them whether the invoice, receipt, or transfer screenshot is authentic, tampered, or a resubmission. The verdict drives payment directly through Squad. No tab switching. No manual cross-checking. Upload, verify, pay.
Built for Squad Hackathon 3.0, Challenge 01: Proof of Life.
A vendor submits an invoice. Before the finance team releases payment, they upload it to TraceLens. The system runs four independent checks in about 3 seconds, scores the document from 0 to 100, and returns a verdict: Verified, Flagged, or Rejected. If approved, the finance officer clicks once and Squad transfers the money directly to the vendor's bank account. The entire flow lives inside one interface.
The four checks run in parallel. OCR reads the document and extracts structured fields: amounts, dates, reference numbers, sender and recipient names, account numbers. The tampering detector runs Error Level Analysis on the image to surface compression artifacts from editing, then passes the ELA output through a fine-tuned EfficientNet B3 to classify it as authentic or tampered. The duplicate checker computes a perceptual hash and a ResNet50 embedding for every document and compares them against the full submission history using Hamming and cosine similarity. The trust score engine combines all four signals into a weighted score, applies penalties for missing fields or detected duplicates, and maps the result to a verdict that drives the payment action.
BuildRight Ltd is a construction company paying 40 vendors a month. Their finance manager Funke uploads every invoice before approving payment.
Tunde Electricals sends an invoice for N450,000. Funke uploads it. TraceLens scores it at 87. Verdict: Verified. Funke approves. Squad transfers N450,000 directly to Tunde's GTBank account. The audit log records the document, the score, the breakdown, and the transfer reference. Done.
Two weeks later, Tunde's apprentice edits the same invoice in Photoshop, changes N450,000 to N4,500,000, and submits it claiming it was a new job. TraceLens runs the same checks. The tampering detector flags ELA artifacts around the edited digits. The duplicate checker finds 94% similarity with the invoice from two weeks ago. Score: 19. Verdict: Rejected. Payment blocked. BuildRight just saved N4,050,000 without Funke having to do anything.
A completely new "vendor" submits a fabricated invoice for consulting services that never happened. The document looks professional. But the payment reference OCR extracts does not match any real Squad transaction in BuildRight's account. Metadata consistency fails. Score: 31. Rejected.
Squad is not just the payment processor here. It is the source of truth that closes the verification loop, because a document can look authentic and still be fraudulent if the payment it claims to represent never actually happened.
When a business connects TraceLens during onboarding, the platform calls Squad's Virtual Account API and assigns the organization a dedicated GTBank NUBAN account number. This is the Squad wallet that all payouts draw from. The finance team funds it through Squad's normal channels.
When a finance officer approves a verified document, TraceLens calls Squad's payout API with the vendor's bank account number and bank code stored in their payee profile, and the transfer goes out immediately. The payment verification endpoint also cross-checks any submitted transaction reference against Squad's transaction records and compares the verified amount against what OCR extracted from the document, which is how TraceLens catches fake receipts that reference real-looking but non-existent transaction IDs.
Squad webhooks hit the Node backend on charge.completed, payment.success, and transfer events. The backend validates the HMAC SHA512 signature on every incoming webhook before processing it. In sandbox mode, TraceLens exposes a simulate funding endpoint that calls Squad's virtual account payment simulation API, so the entire payment flow from document upload to vendor payout can be demonstrated live without moving real money.
The core question TraceLens is trying to answer is whether the pixels in a submitted document are telling the truth. When someone edits a JPEG image and saves it, the edited regions go through a different number of JPEG compression cycles than the surrounding pixels. Error Level Analysis surfaces this by re-saving the image at a controlled quality level and computing the difference. Authentic images produce a relatively uniform ELA output. Edited images produce bright spots at the locations where edits were made because those regions have inconsistent compression histories.
TraceLens applies ELA to every uploaded document and feeds the resulting image into a fine-tuned EfficientNet B3 neural network. The backbone is frozen on ImageNet weights, and a custom classification head (Dense 512, Dense 256, Dense 2) was trained from scratch on 800 synthetic financial documents generated locally using Pillow, covering receipts, invoices, and transfer confirmations with randomized amounts, dates, names, and currencies across six currency types. Each authentic document has a corresponding tampered version produced by one or more of five tampering methods: digit swapping, copy-move forgery, selective recompression, Gaussian blur injection, and regional color shifting. Training runs on CPU in about 45 minutes and achieves 73% validation accuracy. The ceiling reflects the limitation of frozen ImageNet features on ELA data, but the model works alongside a signal processing layer that runs independently.
The signal processing layer computes the ratio of suspiciously bright pixels in the ELA output as a measure of localized editing activity, and the variance of noise levels across image quadrants as a measure of inconsistency between regions. The final tampering probability is a weighted combination of the model prediction at 70% and the signal analysis at 30%, which means the system retains detection capability even on document types the model has not seen.
Duplicate detection uses a perceptual hash computed from the DCT of an 8x8 grayscale representation of the document, and a 2048-dimensional embedding from a pretrained ResNet50 with the classification head removed. Both are stored in Supabase for every processed document and compared against the full history on every new upload using Hamming similarity for the hash and cosine similarity for the embedding. This catches resubmissions even when the document has been resized, cropped, re-saved at a different quality, or given a different filename.
Any business that processes payments based on submitted documents. Construction and real estate firms processing contractor invoices and payment proofs. Oil and gas companies verifying supplier invoices for drilling equipment, maintenance contracts, and logistics services where a single fraudulent invoice can be worth hundreds of millions of naira. Manufacturing companies handling raw material invoices and tooling supplier bills across complex supply chains. Telecoms verifying contractor invoices for tower installations and cable laying projects. Aviation companies processing MRO supplier payments and ground handling contractor bills. Government procurement offices verifying contractor payment proofs before disbursement. FMCG distributors handling constant flows of delivery receipts and warehouse invoices. Any fintech or large enterprise running accounts payable at scale.
The sweet spot is businesses large enough to have a real accounts payable workflow but without a dedicated fraud team. TraceLens gives a one-person finance department the detection capability of a fraud analyst sitting next to them on every document they process.
Three services, each doing one job. The Python ML backend is the verification engine handling OCR, tampering detection, duplicate checking, and trust scoring, storing everything in Supabase. The Node.js backend is the application layer handling authentication, organization setup, payee profiles, Squad payments, and audit logging, proxying document uploads to the ML backend and orchestrating payment flows through Squad. The React frontend is the product interface.
Python ML backend: FastAPI, PyTorch (EfficientNet B3, ResNet50), EasyOCR, Supabase
Node.js backend: Express, TypeScript, MongoDB, Squad API
Frontend: React, TypeScript, Tailwind CSS
TraceLens/
backend/ Python ML backend (FastAPI)
node-backend/ Node.js application backend (Express + TypeScript)
frontend/ React frontend
assets/ Screenshots and architecture diagram
Python ML backend:
cd backend
pip install -r requirements.txt
cp .env.example .env
uvicorn main:app --reload --port 8000Node backend:
cd node-backend
npm install
cp .env.example .env
npm run devFrontend:
cd frontend
npm install
npm run devThe Node backend expects the Python ML backend at ML_BACKEND_URL=http://localhost:8000 and runs on port 4000.
cd backend
python prepare_data.py
python train.py --data_dir data --epochs 15 --batch_size 8 --input_size 256Generates 400 synthetic financial documents and their tampered counterparts, then fine-tunes only the EfficientNet B3 classification head while keeping the backbone frozen. Runs in about 45 minutes on CPU.
Thomson (frontend and Node.js backend) and Omojire (Python ML backend and ML pipeline)