A mechanical engineer walked into a bank and found a bigger machine. Sixteen years later, he mechanised his own DevOps.
Long before I worked in a bank, I was the person who opened things to see how they worked. Computers mostly — disassembled and put back together without training or manuals, on the assumption that anything built by a person could be understood by one. Nothing about that was strategic. It was just the shape of my attention.
That attention took me through Ideal School & College, then Notre Dame College, then the Islamic University of Technology on a full OIC scholarship, where I read for a B.Sc. in Mechanical Engineering. There I learned the formal version of what I had been doing informally: a machine is a system of parts under constraint. Understand the constraints and you can predict the behaviour. Change the constraints and you change what the machine can be.
Then I did something that looked, to everyone including me, like leaving engineering behind. I took an MBA at North South University — summa cum laude — and joined a bank.
I entered BASIC Bank PLC in October 2009 as an Assistant Manager at a branch in Chittagong. I expected a job. What I found was a bigger machine.
A bank is not a building or a balance sheet. It is a mechanism: inputs, tolerances, interlocks, failure modes, and rules that either hold under load or don't. Over nearly seventeen years I was posted through most of its subsystems, and each one taught me something the one before it couldn't.
I operated SWIFT from 2009. I became its administrator in 2024, and today I am the sole SWIFT administrator for the entire bank network, alongside ISO/IEC 27001:2022 Lead Auditor certification and the CBPR+ ISO 20022 migration, which I also train internally. Somewhere in those nearly seventeen years the engineer never left. He simply had a much more interesting machine to study.
Public evidence from Stripe, Notion, Brex, and Adyen shows that the most defensible AI hiring niche in fintech right now is not generic model-building. It is secure agent runtimes, permissioning, approval gates, fraud and risk controls, and machine-enforceable policy — the exact discipline of a bank's compliance and controls function, translated into code.
I did not learn to code my way into AI. I mechanised DevOps the same way I mechanised trade finance operations: by finding the constraints, writing them down as enforceable rules, and building a system that cannot silently violate them.
In March 2026 I started building an AI system of my own. Not as a career move — I had a demanding executive job — but because the question wouldn't leave me alone: how much of my own operational work could be made autonomous, and governed well enough that I would trust it?
The conditions were not favourable. One consumer laptop with 2 GB of video memory. No institutional backing; a grant application had already been rejected. No team. No budget for cloud compute, and no willingness to put my thinking inside someone else's infrastructure. The work happened in evenings and in the early hours, after full days of a job that does not get easier.
I treated every one of those limits as a design input rather than an excuse. That is not resilience talking. It is engineering: constraints are what make a design specific.
What emerged is NINA — a local-first, multi-agent AI infrastructure that runs on that same hardware. Commands enter over Telegram, pass through a sanitisation gateway, and reach build and audit engines that sit behind a governance layer: constitutional rules, compliance scoring, file registries, semantic memory. Inference is tiered, preferring local and low-cost paths before anything paid. Every change is a governed transaction rather than a blind edit.
Two things power work like this, and they are not the same thing.
The first is dopamine — the build loop. Idea, dispatch, result, in seconds rather than the weeks institutional work takes. That loop is productive and mildly addictive, and it is the honest explanation for how nearly seven thousand commits landed in a single thirty-day window.
The second is adrenaline — the 2 a.m. sessions, the pressure of doing this alongside a full executive job, the sense that a window is open and will not stay open. Adrenaline finishes things. It also degrades judgment, and it does not renew.
I mention both because an engineer should know what his own system runs on. Building rewards dopamine; every few minutes something works. The phase after building — writing to people, waiting, being told no — pays out slowly and rewards patience instead. Knowing which fuel you are burning, and which one the current phase actually requires, is part of running yourself well. It is the same discipline I built into NINA: measure the system you are operating, including when that system is you.
It took me embarrassingly long to see the obvious description of my own work.
I am a mechanical engineer. Mechanical engineers mechanise things — they take a process performed by hand and build a mechanism that performs it reliably, repeatably, within tolerance, with failure modes understood in advance.
I did not learn to code my way into AI. I mechanised DevOps. The substrate changed from steel to pipelines, agents and runtimes. The discipline did not change at all.
That is why NINA is built the way it is. It is not a chatbot with ambitions; it is a mechanism. It has interlocks, because mechanisms that can act need places where they must stop. It has an audit engine, because a machine you cannot inspect is a machine you cannot trust. It has thermal and resource guards, because every real mechanism operates inside physical limits — a fact software people can forget and mechanical engineers cannot.
Those numbers are computed from the repository, not written by hand. But the number that matters most is a different one: I hand-wrote almost none of that code.
I specified it. I governed it. I dispatched it to agents, reviewed what came back, rejected what drifted, and enforced the architectural rules when no one else was there to enforce them. Which is, once you look at it plainly, the same thing I have done for nearly seventeen years in a bank: write instructions precise enough that someone else can execute them without ambiguity, and an auditor can verify them afterwards. I ran a specialised LC unit that way. I run an agent mesh the same way.
NINA is not a product, not for sale, and not production-grade. She is a personal capability project under active development, and as I write this she is mid-refactor with services deliberately halted for a system-wide deduplication pass. I state that plainly because honest scoping is the first skill of anyone who sells governance. What she proves is one thing, and proves it well: that I can research, design, build and govern working AI systems with my own hands.
I asked three frontier models, in separate sessions, to assess the system and its maker — with explicit instructions to name no tools and disclose no internals. Their answers are published on the hub, unedited.
I do not offer them as proof of quality. A model's praise is generated on request and is worth exactly what you paid for it. I publish them because independent sessions, given the same constrained question, converged on the same structural observations: that the architecture enforces one canonical source of truth per domain; that the classification rests on implemented capability rather than branding; and that the combination of constrained resources with uncompromised ambition, held to architectural discipline by a single person with no team to enforce it, is uncommon.
The measured numbers live in the updates log, where they can be checked. Opinions belong in one place and instrument readings in another. Keeping them apart is most of what integrity means in this work.
I am not selling NINA and I am not claiming to be something I am not. What I have is a combination that is genuinely hard to assemble: custody-grade compliance experience — SWIFT administration, ISO 27001 audit, ISO 20022 migration, sanctions screening, nearly seventeen years inside a regulated institution — sitting in the same person as demonstrated ability to design, build and govern autonomous AI systems on hardware that has no right to run them.
Most organisations have people who understand one side. The translation between them is where projects fail, budgets vanish, and governance becomes a document nobody enforces. That translation is what I do.
My own bank employs an entire IT department. None of them built this. A trade finance AGM built it alone, in the evenings, on a 2 GB VRAM laptop. That is not a boast — it is the measurement.
The dated career record, the architecture diagram, the independent due diligence and the business-value mapping all live in the evidence file. I take on custody-grade governance discipline applied to autonomous AI systems — architecture, oversight, and enforceable operating rules for organisations that cannot afford an ungoverned agent — AI infrastructure design, local-first deployment for organisations that cannot or will not send their data elsewhere, and SWIFT / ISO 20022 / trade finance consulting from someone who administers these systems today rather than having read about them.
Research, build, repeat. That is the loop. NINA is the evidence that it works under real constraints — and the next system built with it can be yours.