ANCLA

Inspiration

Online fraud prevention often creates a difficult tradeoff in that additional verification can stop fraudulent activity, but showing the same challenge to every customer can also introduce unnecessary friction and cause legitimate purchases to be abandoned.

That led us to ask ourselves: Can a system estimate when verification is worth its cost for a particular transaction, while still enforcing independent safety limits?

ANCLA explores that question through a causal decision framework. It compares the expected outcomes of two possible actions: allowing the transaction to proceed or recommending additional verification.

What it does

ANCLA evaluates a purchase attempt and recommends either allow or verify. For each action (a), the system estimates an expected cost:

Estimated cost of allowing = (amount × probability of successful fraud when allowing)

(probability of a legitimate purchase × probability of abandonment when allowing × amount × abandonment cost rate)

Estimated cost of verifying = (amount × probability of successful fraud when verifying)

fixed verification cost
(probability of a legitimate purchase × probability of abandonment when verifying × amount × abandonment cost rate)

It then prefers the action with the lower estimated cost, subject to independent guardrails for fraud risk, transaction amount, expected loss, missing context, and unusual activity.

The interface explains the recommendation, displays the estimated costs and completion probabilities, and shows which safety rules were activated. ANCLA is a recommendation prototype: it does not execute a payment or perform the verification challenge itself.

How we built it

We built ANCLA as a full-stack web application using React, TypeScript, and Vite for the frontend, with Python and FastAPI for the backend.

Our inference pipeline uses regularized probability models in a T-learner architecture. Separate models estimate outcomes under allow and verify, allowing us to compare their conditional expected costs. Because we did not have access to real-life adjudicated banking data, we trained and evaluated the prototype using randomized synthetic transactions and clearly surface that limitation in the application.

MongoDB Atlas stores purchase attempts, recommendations, and reported outcomes. Previous transaction context and resolved verification outcomes can then be transformed into features for later recommendations; the model does not automatically retrain from demo activity.

We also integrated Capital One's Nessie API to validate account, customer, and merchant context through its available read-only endpoints. A server-side gateway keeps backend credentials out of the browser, and the application is configured for deployment on Render.

Challenges we ran into

Our biggest challenge was separating two very different costs: fraud loss and the friction experienced by legitimate customers. Treating a blocked fraudulent attempt as equivalent to a legitimate customer abandoning verification would have produced misleading labels, so we modeled those outcomes separately.

We also had to manage overfitting and extrapolation while working entirely with synthetic data. We used regularization, independent validation seeds, calibration metrics, causal refutation tests, training-range warnings, and deterministic safety guardrails. These checks helped us evaluate whether the pipeline learned the simulator's intended signal without overstating its readiness for real banking traffic.

Finally, we had to balance model design, API integration, security, testing, deployment, and interface clarity within the hackathon's time limit.

Accomplishments we're proud of

In less than 24 hours, we built an end-to-end application that produces explainable, history-aware recommendations rather than only displaying a risk score.

We are especially proud that the app exposes the reasoning behind each decision, preserves conservative safety limits, distinguishes reported abandonment from confirmed fraud, and communicates where the model is operating beyond its training support.

What we learned

We learned that building a complex responsible decision system involves much more than just training a predictive model. The meaning and timing of each label, the source of every feature, and the behavior of the system when context is missing are just as important as model accuracy.

We also improved how we collaborated in a shared repository by dividing work across the frontend, backend, modeling, testing, and deployment layers; using focused commits and pull requests; and resolving integration conflicts under time pressure.

On the security side, we learned to keep credentials server-side, protect the backend with service authentication, and expose only an allowlisted set of operations through the frontend gateway.

What's next for ANCLA

Our next step is to validate the approach with representative, properly governed real-world data. That would require confirmed fraud outcomes, verification assignments, voluntary-abandonment labels, and timestamps collected separately so that the causal assumptions can be tested rather than presumed.

We would also evaluate calibration and fairness across relevant customer segments, run temporal holdout tests, and measure performance under changing fraud patterns. With appropriate consent and governance, additional signals such as transaction time, location consistency, device context, and merchant history could improve the recommendations.