Enfacial

On a campus, small payments happen constantly. A canteen meal, a print job, a hostel laundry token. Every one of them asks the same thing: find your phone, unlock it, open an app, scan a code, wait for a network round trip.

It is a tiny friction, but it repeats hundreds of times a day across thousands of people. Cards get lost. Phones die. Cash creates queues. The credential is always something you have to carry, and carrying is exactly the part that fails.

A campus is a rare thing: a bounded population, a shared operator, and a controlled physical environment. That combination makes an idea viable here that would be reckless on the open internet: using a face as the credential.

The interesting question was never "can we match faces." It was "can we do it in a way people would actually trust," which is a systems and privacy problem far more than a model-accuracy problem.

If authentication happens on-device, and the system stores mathematical representations rather than images, then face-authenticated payment could be both faster than a QR flow and defensible on privacy grounds.

The wager: remove the object you carry, and the whole interaction collapses to a single step: look, confirm, done.

A payment terminal for merchants, a mobile app for users to enrol and manage their wallet, and an admin layer for the campus operator to manage accounts, limits and settlements.

Enrolment is deliberate and explicit. Spending is fast. Everything sensitive stays close to the edge.

During enrolment the app captures a face and derives an embedding, a numerical representation, not a stored photograph. At a terminal, a live capture is converted the same way and compared against enrolled embeddings for that campus.

A confirmation step and a spending limit sit on top, so a match alone never silently moves money.

Three surfaces (terminal, user app, admin) over a shared identity and ledger service. Face processing is pushed as close to the device as possible to reduce both latency and the amount of sensitive data that ever leaves the edge.

The ledger is treated as the source of truth; the face layer is an authentication front-end to it, not the system of record.

On-device inference over a cloud face API, for latency, for offline resilience, and because it makes the privacy story real rather than rhetorical.

Store embeddings, never raw images. Scope every biometric to a single campus namespace. Keep the money ledger boring and auditable, and let the interesting work live in the capture and matching path.

The technical core worked: enrolment, matching and a confirmed payment flow. The harder lessons were environmental: lighting, camera quality and angle move real-world accuracy around far more than a clean test set suggests.

TODO: verify any pilot, deployment or usage figures before publishing them here.

Selling to an institution is not selling to a user. Procurement, ownership, liability for money movement and the question of "who is accountable if it goes wrong" matter more than the demo.

A payment system also has a cold-start problem on both sides: merchants won't install without users, users won't enrol without merchants.

The model was never the bottleneck. Trust, deployment and the institutional sale were. A privacy-first architecture is not just ethics. It is the thing that makes the sale possible at all.

Start with the narrowest possible wedge (one merchant type, one clear reason to use it) instead of a general-purpose campus payment platform. Design the institutional sale as early as the product.

The core idea (invisible, privacy-respecting identity in a bounded space) is bigger than payments. Access, attendance and personalisation are all the same primitive wearing different clothes.