Key Responsibilities & Outcomes

• Own end‑to‑end platform reliability, availability, and operational health, including incident and problem management.

• Lead and develop a high‑performing engineering and support team with clear accountability and ownership.

• Act as senior engineering escalation point during major incidents and customer‑impacting events.

• Drive improvements across architecture, engineering discipline, observability, and operational processes.

• Partner closely with customers, internal stakeholders, and regional leadership to build trust and transparency.

• Ensure strong governance, high‑quality root‑cause analysis, and measurable reduction in recurring incidents.

• Represent engineering in service reviews, governance forums, and executive‑level discussions.

• Champion Mastercard values, inclusive leadership, and a culture of engineering excellence.

• Act as a liaison between Customer Success and Technical teams (Business Ops / Tech Ops / Engineering).

• Coordinate and quantify customer impact from incidents, and ensure timely communications with accurate service impact details are issued through Customer Success in line with regulatory and contractual requirements.

• Oversee service performance adherence, ensuring high-quality service and compliance with service levels.
  Identify service risks, improvement opportunities and drive actions to enhance service performance.

• Coordinate and produce service reports, review and provide business input to post incident reports, monitor and report service usage trends, and lead capacity forecasting and planning in line with the agreed models.

• Provide governance for RTP service changes with internal stakeholders and the customer, safeguarding service stability and resilience by ensuring the appropriate service change process is followed and all service changes are tested, coordinated and executed properly.

• Act as the service mapping custodian and ensure the service design meets requirements.

• Be available 24/7 for critical live service incidents, act as the critical incident escalation point for the customer, and provide critical incident support coverage.

• Work internally to ensure all technical teams adhere to the OLAs.

• Incident & Issue Leadership

• Coordinate incident resolution and root cause analysis process across various internal teams, in accordance with Mastercard and RTPI policies and procedures.

• Manage the flow of information from internal teams through to the customer, ensuring timely, accurate and clear communications are provided to maintain a strong customer relationship.

• Risk & Improvement Management:
  -Maintain and update the RTPI Service Risk Register. Own RTP service risks, drive internal teams for proper risk assessment and mitigation actions.

  • Develop and execute continual improvement plans for service delivery within a specific market. Work with internal stakeholders to share improvement opportunities and plans.
  • Oversee customer change and service improvement requests, working with stakeholders across Technology and Operations, Product, Engineering, Security and the Region (amongst others) to - ensure these are prioritised, delivered and accepted in accordance with Mastercard and RTPI standards.

All About You

• Senior engineering leadership experience in high‑availability, mission‑critical platforms (payments, financial services, large‑scale distributed systems).
• Strong technical foundation in distributed systems, real‑time processing, and production operations.
• Proven experience leading teams through complex incidents and operational challenges.
• Strong customer and stakeholder management skills, including executive‑level engagement.
• Ability to balance delivery urgency, risk management, and long‑term platform health.
• Clear communicator who remains calm and credible under pressure.
• Demonstrates Mastercard leadership expectations: ownership, customer focus, thoughtful risk‑taking, and inclusive people leadership.
• Corporate Security Responsibility

All activities involving access to Mastercard assets, information, and networks comes with an inherent risk to the organization and, therefore, it is expected that every person working for, or on behalf of, Mastercard is responsible for information security and must:

• Abide by Mastercard’s security policies and practices;
• Ensure the confidentiality and integrity of the information being accessed;
• Report any suspected information security violation or breach, and
• Complete all periodic mandatory security trainings in accordance with Mastercard’s guidelines.
• Strong production mindset with proven experience resolving complex live‑site issues.

Skills

• Track record of making swift, informed decisions during incidents and service disruptions.
• Experience building strong relationships with senior stakeholders, regulators, and external partners.
• Skilled in managing customer escalations and driving satisfaction through proactive engagement.
• Proven experience managing incident response, root cause analysis, and post-incident reviews.
• Ability to communicate clearly and confidently with customers during critical events.
• Strong background in risk identification, assessment, and mitigation strategies.
• Familiarity with regulatory compliance and reporting obligations in the local market.
• Experience monitoring service health, analysing KPIs/SLAs, and driving operational improvements.
• Skilled in developing and executing service improvement plans across technology and operations.
• Solid understanding of payments technology, infrastructure, and operational processes.
• Experience working in multi-market or global environments with complex stakeholder landscapes.
• ITIL qualification preferred.

about me #

I have been a long time system architect and team lead with over two decades of experience in designing, building, and delivering mission-critical, high-availability systems across diverse domains, including finance, public sector, and smart city initiatives. At work I am always passionate about solving challenges to enhance people’s experience. I consistently adopt a systematic approach and follow best practices which encourages me to think deeper and discover better solutions. At the same time, I am practical to find a optimal solution and meet the project deadlines. I have handson experience across various system architectures - monolith, service-oriented architect, the modern microservices, PaaS，Saas，FaaS，CaaS - I have learned and gained insights of different cutting-edge technologies. I have both inhouse banking development experience as well as consulting experience from tech companies.

work experience #

UOB #

Currently, as First Vice President at UOB’s Group Enterprise Banking, I lead a team of over 20 developers in delivering a comprehensive payment system that has transformed UOB’s Asia operations. This project, the largest in the department’s history, introduced 20x more payment product features, achieved 99% environment availability, and met stringent engineering KPIs. By leveraging AI tools for productivity and implementing robust governance practices—such as database standards, code quality gates, and security protocols—I ensure high-quality, compliant, and maintainable systems.

My time at UOB has been a significant learning experience, where I successfully led a team to deliver a complex, high-impact payment system despite challenging circumstances. However, the engineering culture has been difficult, with a heavy reliance on contract staff, unrealistic management expectations, and an intense work schedule that often extended from 9 AM to 9 PM, six days a week. I’m seeking an environment where sustainable engineering practices, long-term team growth and mission-driven impact align more closely with my values.

Across my career, I’ve consistently stayed where I could own meaningful outcomes and deliver in mission-critical environments.

Karat System Patterns — Mastercard RTP (Director, Software Engineering) #

Role lens: This is a production-operations and reliability leadership role, not greenfield build. Responsibilities are incident/problem management, senior escalation during major incidents, RCA, observability, service reviews. Every system answer should bend toward reliability and recovery — close each one with the operational consequence ("…and when X fails at 2am, this is what bounds the damage and makes RCA fast"). That move separates a senior-IC answer from a Director of Engineering Excellence answer.

Answer rapid-fire trivia in 1–2 crisp sentences. Don’t lecture. Lead with the tradeoff, then the production framing.

System patterns #

1. Distributed transactions — Saga vs 2-Phase Commit #

Say: “2PC gives strong consistency but the coordinator blocks participants and is a latency and availability liability — one slow node stalls everyone, and a coordinator failure leaves locks held. For real-time payments I lean on a Saga with compensating transactions: each step commits locally and publishes an event, and failures trigger compensation rather than a distributed lock. I trade atomicity for availability and bounded latency, and accept that I now engineer idempotency and reconciliation.”

2. Exactly-once / idempotency — the core RTP problem #

Say: “Exactly-once delivery is a myth across a network; what you engineer is at-least-once delivery plus idempotent processing, which gives exactly-once effect. Every payment carries an idempotency key — the UETR or a derived dedup key — and the processing side checks a dedup store before applying. A retry or duplicate hits the same key and is a no-op. That’s how you survive redelivery without double-debiting.”

3. CAP in a payment partition #

Say: “In a localized partition I default to consistency over availability for the ledger — a payment system must never double-spend or lose money, so the safe failure is to reject or hold, not accept on a node that might be wrong. But I qualify it: I’d rather degrade gracefully — fail fast, return a clear in-doubt status, queue for reconciliation — than hard-stop. The nuance is which operations: authorization needs CP; read-only status lookups can stay AP.”

The qualification is the senior signal. Don’t just recite “CP.”

4. In-doubt / in-flight transactions — your differentiator #

Say: “An in-doubt transaction is one where I sent a request but didn’t get a definitive response — I don’t know if it applied. I never blindly retry, because that risks a double payment. I resolve it with an idempotent status inquiry against the same key, or a timeout-driven reversal, and everything lands in a reconciliation process. In-doubt handling is the heart of real-time payments reliability.”

Tie to the IOL two-HACK async inquiry pattern if it comes up — production experience beats theory.

5. Active-active architecture & failover #

Say: “Active-active gives availability and survives a site loss, but forces a hard question on write conflicts and ordering. For a ledger I’d partition by account or key so a given account is mutated in only one place at a time — avoiding the conflict rather than resolving it after. Failover then needs careful state handling: in-flight transactions must be recoverable, which comes back to idempotency and a durable outbox.”

Mention Data Guard / outbox / saga from IOL — lived experience.

6. Message ordering & delivery guarantees #

Say: “Ordering matters when events are causally dependent — you can’t apply a reversal before the original. I get it from partitioned, keyed queues (same account/key → same partition → ordered), not global ordering, which doesn’t scale. Where strict order isn’t required I relax it for throughput. And I design consumers to tolerate out-of-order or duplicate delivery anyway, because the network will eventually hand me both.”

7. Idempotent retries, backoff, and poison messages #

Say: “Retries need exponential backoff with jitter to avoid retry storms during a partial outage, a cap, and a dead-letter queue for poison messages so one bad payload doesn’t block a partition. The DLQ feeds an alert and a remediation path — that’s an operational control, not just a code pattern.”

Lead with the operational framing; that’s the role.

8. Observability & SLA ownership — unique to this role, most candidates miss it #

Say: “For a mission-critical RTP platform I instrument the golden signals — latency, traffic, errors, saturation — plus payment-specific SLIs: in-doubt rate, reconciliation lag, end-to-end settlement time. SLOs drive error budgets, error budgets drive whether we ship or stabilize. During an incident, observability turns ‘something’s wrong’ into a bounded blast radius and a fast RCA.”

Bringing this up unprompted signals you read the role correctly.

Java / low-latency core (rapid-fire trivia) #

Thread-safety for shared data
“volatile guarantees visibility but not atomicity; for a counter I’d use AtomicLong or LongAdder (better under contention); for compound state, a lock or a ConcurrentHashMap. I reach for immutability first — no shared mutable state, no problem.”

GC for low-latency
“Low-latency payments means avoiding stop-the-world pauses. On Java 21 I’d run ZGC or Shenandoah for sub-millisecond pauses, size the heap to limit GC frequency, and profile allocation rate — the real fix is usually reducing garbage, not tuning the collector. I watch p99/p999 latency, not averages, because a GC pause hides in the tail.”

Pass-by-reference
“Java is strictly pass-by-value; for objects the value passed is the reference. You can mutate the object the reference points to, but reassigning the parameter doesn’t affect the caller. It’s pass-by-value-of-the-reference.”

Concurrency extras they may toss in

• CompletableFuture — async composition without blocking threads.
• Virtual threads (Java 21) — high-concurrency I/O-bound payment flows without thread-pool exhaustion.
• synchronized vs ReentrantLock — the latter gives tryLock / timeout / fairness.

The one strategic reminder #

Close every system answer with the operational consequence. When you explain a pattern, land it with: “…and the reason that matters in production is, when X fails at 2am, this is what bounds the damage and makes RCA fast.” That is the difference between interviewing as a senior engineer and interviewing as the Director of Engineering Excellence — which is the actual role.