Khan Bank systems

Four years as a Senior Software Engineer at Chinggis Systems, on systems delivered into Khan Bank's environment. Teams of roughly eight to fourteen engineers, with the larger internet-banking work involving a group of about thirty.

The products were collaborative. I did not build the bank platform alone or own every backend. My contribution came through early technical learning, implementation, architecture and convention decisions, detailed code review, mentoring, and cross-team delivery.

Additional queue, call-centre, operational, and internal systems existed alongside these.

One of the first major projects needed Angular. The team did not yet know Angular, and the deadline did not pause while we learned it.

Components, services, routing, and state come from documentation. The team's real questions did not:

• where should feature boundaries sit in a long-lived banking application;
• how should shared state and API failure behave across screens;
• which conventions let several engineers work without producing several local architectures;
• how does a reviewer distinguish a preference from a rule the product depends on;
• how does a new engineer find a working example instead of rediscovering every decision?

I learned Angular against the corporate-banking product itself, then turned the result into examples, conventions, pair support, and review feedback. The test was whether teammates could deliver without waiting for me to implement their feature.

When later internet-banking work moved toward React, I studied it with two colleagues before helping the wider team adopt it.

At roughly thirty people the framework choice was the easy part. The migration was the shared decisions: component boundaries, state, error behaviour, naming, API contracts, and review. A locally elegant pattern nobody else could apply was not a useful standard.

The working method was to teach with code already connected to the real product, then keep the convention visible in review until it became ordinary team behaviour.

Later work moved into AWS and serverless patterns. Again the challenge was not collecting service names — it was deciding where asynchronous work, failure, observability, deployment, and cost belonged in a bank's operational model.

The same loop applied: understand enough of the unfamiliar system to make a real delivery decision, document the boundary, help the team use it, and let production expose what the model missed.

I was known for pull requests carrying twenty or more comments. Many caught real problems: duplicated logic, unclear state, missing failure behaviour, inconsistent conventions, or code that would be expensive to support across several banking products.

The outcome I cared about showed up months later, when younger engineers stopped receiving the same class of comment — they had internalised the model behind the feedback.

The delivery of a standard matters as much as the standard. Explain the governing reason first, separate blocking risk from preference, point to an example, and leave the engineer a path to own the correction.

Banking software lives inside audit requirements, release windows, operations teams, security review, legacy contracts, and the cost of breaking a live customer workflow.

The cleanest rewrite is often the wrong decision there. An incremental design with explicit recovery and a migration path can be stronger than an isolated architecture that assumes the organisation will reorganise around it. Deployment, support, and team understanding belong inside the architecture frame, not after it.

Customer-facing and internal banking systems reached production, and Angular, React, and later cloud approaches moved from unfamiliar territory into repeatable team capability.

The strongest outcome was not that I personally knew more frameworks. It was that unfamiliar technology stopped being a delivery blocker for the team.