Skip to main content

Implementing JIRA for Support of Program-Trading in Corporate Banking: My Experience

· 3 min read
JIRA Support for Trading

By Alex Ivanov, Application Support Engineer, 2007

Working in first-line support for program-trading platforms in a corporate bank is both a privilege and a stress test for any engineer. Our clients — corporate traders using custom-built order management systems — expect speed, clarity, and no-nonsense solutions. When I joined the team, support was handled mainly via shared inboxes, spreadsheets, and the occasional hallway shout. As ticket volumes and system complexity grew, it became clear: we needed real incident management.

Why JIRA? And Why Now?​

At first, JIRA seemed like overkill. It's everywhere in software, but most traders and even some IT people saw it as "just for developers." But I knew from my previous roles that, set up right, JIRA is much more:

  • It lets us track every complaint, outage, and question, not just bugs.
  • It creates a full audit trail — essential for regulated banking.
  • Most importantly, it can adapt to our custom workflows and connect directly with integration scripts, databases, and alerts.

The Rollout — And Initial Pushback​

Our pilot started with just the support team. We built a simple incident workflow:

  1. New incident created (manually or via email integration)
  2. Triaged and assigned (with priorities linked to business impact)
  3. Work logs and updates tracked
  4. Resolution, post-mortem, and closure

Traders were skeptical. "Do I really have to file a ticket? Can't I just call support?"
But as we started linking incidents to root causes — and showing stats on recurring issues — even the loudest skeptics saw value. For the first time, they could see response times and progress on their own tickets.

Engineering Details: Integration and Training​

We integrated JIRA with our monitoring tools, so some alerts auto-created tickets with logs and error context. For critical incidents (system outages, broken integrations), we linked tickets directly with release deployments and rollbacks.

I also spent time training new 1st-line colleagues — not just on "how to use JIRA," but on why it matters for transparency, ownership, and knowledge sharing.

  • We created a playbook for triage and escalation
  • Used labels and custom fields for different applications and desks
  • Designed dashboards for management with SLA tracking

The Results — And What I’d Do Differently​

After a few months, we saw:

  • Fewer lost requests: Nothing was "forgotten in email" anymore
  • Better root cause analysis: Repeated issues were easy to spot
  • Improved onboarding: New support engineers learned from ticket histories
  • Less stress: Both for support and for traders, knowing where things stand

It wasn’t perfect — some colleagues still bypassed the process in real emergencies, and JIRA can be slow if over-customized. If I did it again, I'd involve the traders even earlier in workflow design, and keep the ticket forms as simple as possible.

Takeaways​

Introducing JIRA to support corporate traders wasn’t just about a new tool. It was about making support visible, accountable, and scalable in a high-stakes environment.
For any support engineer: Don’t underestimate the value of clear incident management. The right process is just as important as the right technology.

Sources:

  • Personal experience, 1st-line support, corporate bank, 2005–2007
  • Team notes and JIRA dashboards from implementation phase
  • Feedback sessions with traders and IT management