Zecathon: So Close, Yet So Far

🚀 The Challenge Begins

I first heard about Zenith Bank’s Hackathon — Zecathon 5.0 — through a classmate at HatchDev, where I was training as a full-stack developer. I went through the tracks carefully, not just looking for what sounded exciting, but for what mattered. One stood out immediately:

Optimizing the Operational Efficiency of ATMs.

The ₦10,000,000 prize pool was tempting, no doubt. But what truly pulled me in was something bigger: the chance to build a solution that could realistically be deployed by a major Nigerian bank. A real system, for a real problem, used by real people.

With that clarity, I formed a team — Team CyberForce:

• Two backend developers
• One AI/ML engineer
• And myself, leading the team and handling frontend, product thinking, and pitch strategy

Beyond building the product, I took responsibility for shaping an investor-grade pitch deck and a scalability plan that showed this wasn’t just a hackathon demo, but a system that could grow.

✉️ The Email That Changed Everything

About a week after submission, the email arrived.

Out of 497 teams, only 25 were selected for the next phase.

We were one of them.

We had officially made the Top 5%.

The invitation came with details: we were to report to Victoria Island, Lagos, for an intense, on-site build phase running from November 11th to 14th. Three days. One problem. No shortcuts.

That’s when it sank in — this was no longer theoretical.

---

🛠️ The Build Phase Begins

Day 1: From Idea to Execution

Before we even arrived, I had already broken the system down into clear components and assigned responsibilities. Time was our most limited resource, so clarity mattered.

The idea we submitted evolved into a concrete product we named ATM360.

At its core, ATM360 was built to solve what most Nigerians already know too well:

• ATMs going offline without warning
• No visibility into cash availability
• Slow maintenance cycles
• Engineers dispatched too late or to the wrong locations
• Customers hopping from ATM to ATM, guessing

This wasn’t a UI problem. It was an operational intelligence problem.

So we treated it like one.

By the end of Day 1:

• The system architecture was finalized
• Roles and user flows were locked
• Frontend scaffolding was live
• Backend services were being wired
• The AI layer design was clearly defined

No feature bloat. Everything had a purpose.

---

Day 2: Building the Core

Day 2 was all about depth.

We pushed hard on what would differentiate ATM360 from basic monitoring tools.

What We Built

1. Public ATM Locator A live map showing:

• ATM status in real time
• Estimated queue times
• Smart failover routing to nearby working machines

This alone directly reduces wasted time for users.

2. Central Admin Dashboard Designed for bank operations teams:

• Predictive maintenance alerts
• Cash flow forecasting
• Automated fault diagnosis
• Full audit logs for transparency

This is where decision-making shifts from reactive to proactive.

3. Branch Admin Interface For local control:

• Branch-level ATM monitoring
• Issue tracking
• Engineer coordination

Branches finally had visibility instead of waiting blindly.

4. Engineer Mobile Interface Built for speed and accountability:

• AI-driven auto-dispatch
• GPS-based arrival detection
• OTP verification on-site
• Task logging with photo proof

Every step was traceable. No guesswork.

---

🧠 The AI That Tied It All Together

One of the most exciting parts of the build was our custom AI agent, Zeni.

Zeni wasn’t a chatbot slapped onto a dashboard.

It was a domain-aware operational agent that:

• Interprets natural language into system actions
• Retrieves context from internal data (ATMs, logs, tickets, alerts, engineers)
• Dispatches engineers automatically
• Summarizes incidents and generates reports
• Navigates the system via intent-to-execution mapping

All without exposing sensitive system internals.

Under the hood:

• A lightweight custom-trained model
• Two-stage intent engine
• ONNX runtime for speed and control

This layer transformed ATM360 from a dashboard into an assistant.

🛠️ Tech Stack

We kept the stack pragmatic and scalable:

• Frontend: Next.js, TypeScript, Tailwind, ShadCN
• State Management: Zustand
• Maps: Leaflet (my first deep dive into live geospatial systems)
• Backend: Node.js
• AI Layer: Python, custom intent engine, ONNX
• Messaging & Auth: Twilio (OTP verification)
• Predictive Models: Cash flow, network failure, peak-time load

Every choice was deliberate.

---

📊 The Results

Using simulated data modeled after real Nigerian ATM patterns, ATM360 showed:

• 10–15% increase in ATM uptime
• 30% faster repair turnaround
• ~15% reduction in customer ATM search time
• 25% improvement in branch-level transparency

This wasn’t theoretical optimization. It reflected how Nigerian ATMs actually fail and recover.

---

🏁 The Outcome

Pitching on the final day We didn’t win.

And honestly, that stung.

But we walked away having built something real, scalable, and deeply relevant.

Being selected among 25 teams out of nearly 500 validated our thinking. More importantly, ATM360 proved that infrastructure problems in Africa don’t need shallow solutions — they need serious engineering and systems thinking.

This experience changed how I see hackathons, products, and my own growth as an engineer.

ATM360 isn’t the end. It’s a foundation.

And this is just the beginning.