# M. Baizid Alam — The Human Behind the Machine

**AGM, BASIC Bank PLC · Sole SWIFT administrator · ISO/IEC 27001:2022 Lead Auditor · Builder of NINA**
Dhaka, Bangladesh · baizid.alam@gmail.com · +88 0171 348 7996 (Call & WhatsApp)
Canonical: https://aibony.github.io/ | CV: /cv.pdf | Dark CV: /ocv.pdf | Portfolio: /portfolio.pdf

> A mechanical engineer walked into a bank and found a bigger machine. Sixteen years later, he mechanised his own DevOps.

## 01 — The machine came first
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.

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 like leaving engineering behind: an MBA at North South University, and a bank.

## 02 — Then a larger machine
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 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:

- The branch taught me where operational risk actually hides — in everyday transactions performed under pressure.
- Credit taught me how a bank decides whom to trust, and what it costs when that judgment is wrong.
- Trade finance taught me how documents move value across borders, and why one discrepancy can stop a national procurement.
- Head office taught me what a Board actually reads.
- SWIFT taught me custody — the difference between operating a system and being responsible for it.

I operated SWIFT from 2009 and became its administrator in 2024. Today I am the sole SWIFT administrator for the entire bank network, an ISO/IEC 27001:2022 Lead Auditor, and the internal trainer for the CBPR+ ISO 20022 migration.

## 03 — The constraint
In 2024 I began building an AI system of my own. One consumer laptop with 2 GB of video memory. No institutional backing; a grant application had already been rejected. No team, no cloud budget, and no willingness to put my thinking inside someone else's infrastructure. The work happened in evenings and early hours, after full days of an executive job.

I treated every one of those limits as a design input rather than an excuse. Constraints are what make a design specific.

What emerged is NINA: a local-first, multi-agent AI infrastructure running on that same hardware. Commands enter over Telegram, pass through a sanitisation gateway, and reach build and audit engines 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.

### A note on fuel

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 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.

## 04 — What I actually did
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 has interlocks (mechanisms that act need places where they must stop), an audit engine (a machine you cannot inspect is a machine you cannot trust), and thermal and resource guards (every real mechanism operates inside physical limits).

## 05 — What it proves, and what it doesn't
Computed from the repository: 13,620+ commits, 921 Python modules, ~140,863 lines of code, 565 test files — all under a 2 GB VRAM ceiling.

I hand-wrote almost none of it. I specified it, governed it, dispatched it to agents, reviewed what came back, rejected what drifted, and enforced the architectural rules with no team to enforce them for me. That is the same skill I have used 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.

NINA is not a product, not for sale, and not production-grade. She is a personal capability project under active development. Honest scoping is the first skill of anyone who sells governance.

## 06 — What the machines say
Three frontier models, in separate sessions, were asked to assess the system and its maker with explicit instructions to name no tools and disclose no internals. Their outputs are published unedited at https://aibony.github.io/#proof — not as proof of quality (a model's praise is generated on request), but because independent sessions converged on the same structural observations: one canonical source of truth per domain; classification based on implemented capability rather than branding; and the uncommon combination of constrained resources with architectural discipline enforced by one person.

Measured numbers live in the updates log at https://github.com/aibony/aibony. Opinions belong in one place and instrument readings in another.

## 07 — Where this goes
The combination is the value: custody-grade compliance experience — SWIFT administration, ISO 27001 audit, ISO 20022 migration, sanctions screening, nearly seventeen years inside a regulated institution — 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 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 laptop.

**Services:** 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 data-residency-constrained organisations; SWIFT / ISO 20022 / trade finance consulting.

**Hire:** https://www.upwork.com/freelancers/~01a168174960b876b3 · https://www.fiverr.com/s/NN7o0la