Architecting the Corporate Transactions Module
Designing and delivering a full-stack, end-to-end transaction system — from employer portal to regulatory submission — as the sole full-stack engineer on the project.
Pakistan's first digital pension system — and a transaction pipeline that didn't exist yet
Mahaana Wealth is Pakistan's first digital Asset Management Company, backed by Y Combinator (W22). Its core product is a digital pension platform serving over 15,000 users — a mission-critical financial system where every transaction directly affects retirement savings.
Corporate clients — employers enrolling their entire workforce into pension plans — needed a way to initiate deposit and redemption transactions on behalf of their employees. These transactions had to flow through a strict approval chain before reaching CDC (Central Depository Company), Pakistan's national financial clearing authority.
No such system existed. I was assigned as the sole full-stack engineer to design it, build it, and ship it — from the employer-facing UI to the microservice that fires the final API call to CDC.
End-to-end implementation ownership. Working within an established architecture and alongside a lead engineer, I was handed a blank user story and made it production-ready — translating the existing system's patterns into a new, fully functioning transaction pipeline from the first line of code to the final CDC integration.
Three portals, one financial authority, zero margin for error
Pension transactions in Pakistan operate under strict regulatory oversight. A single misrouted or duplicated transaction could mean the wrong amount landing in the wrong account — with real financial and legal consequences. The system had to be correct, auditable, and fault-tolerant by design.
Challenge 01
The employer portal, admin portal, and CDC integration lived across different services. They needed to share transaction state without tight coupling or synchronous blocking calls.
Challenge 02
Admin approval had to be role-gated, with specific Blazor Server UI flows for approvers. Bypassing approval — even accidentally — had to be architecturally impossible.
Challenge 03
The CDC API is an external financial system with its own rate limits, retry semantics, and failure modes. The integration needed to handle failures gracefully without data loss.
Challenge 04
Background jobs processing approved transactions had to be idempotent. A job running twice due to a service restart could not trigger a duplicate CDC submission.
A message-driven approval pipeline with guaranteed delivery
I designed the system around a core principle: each stage of the transaction lifecycle is owned by exactly one service, and transitions between stages are driven by messages — not direct calls. This meant the employer portal, approval service, and CDC dispatcher could fail and restart independently without corrupting transaction state.
“The architecture isn't clever — it's conservative. In financial systems, conservative is the right kind of smart.”
Employer initiates transaction — Corporate Portal (Blazor Server)
I built the transaction creation UI on the Corporate Portal in Blazor Server with C#. The employer selects the employee, transaction type (deposit or redemption), and amount. On submission, the transaction is persisted to the database with a Pending status. No money moves at this stage. A message is published to Azure Service Bus to notify downstream services.
Admin reviews and approves — Admin Portal (Blazor Server, role-gated)
I built a dedicated admin-facing transaction queue on the Admin Portal. Access is controlled by ASP.NET Core role-based authorization — only users with the designated approver role can view and act on pending transactions. On approval, the transaction status is updated to Approved and a second Service Bus message is published. On rejection, the employer is notified and the transaction is marked Rejected with a reason.
Background job picks up approved transaction
I implemented a background job service within the ASP.NET Core microservice layer. The job subscribes to the Approved queue on Azure Service Bus. It reads the transaction, validates the payload, and prepares the CDC-compliant request structure. The job is designed to be idempotent — if it runs twice on the same transaction, the second execution is a no-op.
CDC API submission with retry and error handling
The background job calls the CDC third-party API to submit the transaction. I implemented retry logic with exponential backoff for transient failures. On success, the transaction is marked CDC Approved and the deposit or redemption amount is confirmed to the destination account. On hard failure, the transaction is flagged for manual review and an alert is triggered.
Full audit trail and status propagation back to portals
Every state transition — from Pending to CDC Approved — is logged with a timestamp, actor, and event type. Both the Corporate Portal and Admin Portal reflect the live transaction status via real-time Blazor Server component updates, giving employers and admins a consistent, accurate view of every transaction in the system.
Why Azure Service Bus — and why not direct HTTP calls
The natural instinct would be to have the admin approval trigger a direct HTTP call to the CDC dispatcher microservice. I rejected this for three reasons: tight coupling, no delivery guarantee, and no replay capability.
Azure Service Bus gave me durable message delivery, dead-letter queues for failed messages, and complete decoupling between the approval service and the CDC dispatcher. If the dispatcher is down when an admin approves a transaction, the message sits in the queue and is processed when the service recovers — no transaction is lost.
The dead-letter queue as a safety net. Every unprocessable message is routed to a dead-letter queue with the failure reason. This gave the ops team a recovery path for any edge case — instead of silent data loss, they had a queue of messages to inspect and replay.
For the background job implementation, I chose a hosted service within ASP.NET Core (IHostedService) over a standalone process — keeping the job co-located with the microservice that owned the transaction domain, reducing infrastructure complexity while maintaining clear ownership.
The problems I had to solve that weren't in any spec
Problem
Race condition: two admin users could theoretically approve the same transaction simultaneously, causing a duplicate CDC submission.
Solution
Optimistic concurrency control on the transaction entity — the approval operation checks and updates the status in a single atomic database transaction, making double-approval architecturally impossible.
Problem
CDC API returns non-standard error codes. A mapping layer was needed to translate CDC responses into meaningful internal transaction states.
Solution
Built a CDC response translator in the dispatcher microservice that maps all known CDC error codes to typed internal results, with a fallback to manual review for unknown codes.
Problem
Blazor Server's real-time connection meant admin portal UI had to reflect status changes pushed from a background service — not triggered by user actions.
Solution
Used Blazor Server's built-in SignalR connection with InvokeAsync and StateHasChanged to push transaction status updates from the service layer into live UI components without page refresh.
What shipped, and what it delivered
End-to-end transaction pipeline live in production
The full Corporate Transactions Module — employer portal, admin approval, background job, and CDC integration — was designed, built, and deployed to production by a single engineer with zero critical launch defects.
Zero duplicate or lost transactions at launch
The idempotency design and Service Bus dead-letter queue architecture meant that even in edge-case failure scenarios, no transaction was processed twice or silently dropped.
Corporate onboarding unblocked for all employer clients
Before this module, corporate clients had no mechanism to process transactions digitally. Its delivery unlocked the corporate segment of Mahaana's pension product — directly expanding the platform's revenue capability.
Full audit trail for every transaction state change
Every transition — creation, approval, rejection, CDC submission, confirmation — is logged with actor and timestamp. The compliance team could reconstruct the complete lifecycle of any transaction from a single query.
Decoupled architecture that scales independently
Because each stage communicates via Azure Service Bus rather than direct calls, the CDC dispatcher can be scaled, replaced, or modified without touching the employer or admin portals — giving the engineering team long-term flexibility.
The bigger picture: This wasn't just a feature. It was the infrastructure that made corporate pension transactions legally compliant, operationally reliable, and regulatorily auditable — for Pakistan's first digital AMC, at scale.
What this project taught me about building for trust
Most software mistakes are recoverable. A broken UI can be fixed in a hotfix. A slow query can be optimised. But in financial systems, a lost or duplicated transaction has real consequences for real people — their savings, their employer's records, their regulatory standing.
Working as the sole engineer on this feature sharpened one instinct above all else: design for failure first, then design for the happy path. The dead-letter queue, the idempotency checks, the optimistic concurrency — none of these are visible to the user. But they're the reason the user can trust the system.
I also learned what it means to own a system end-to-end. There was no one to hand a problem off to. Every edge case, every CDC error code, every Blazor Server quirk — it was mine to figure out. That kind of ownership changes how you think about architecture. You stop optimising for elegance and start optimising for reliability.
Interested in working together?
I build production-grade AI and full-stack systems for international clients.
Get in touch