Decoding the Bank's AI Playbook: Donald (OCBC)
MD (Head of Group Data Office) @OCBC
For many enterprise software companies, landing a multinational bank is the holy grail - proof of credibility, scale, and long-term revenue. But banks aren’t like typical customers. Between complex regulatory environments, entrenched legacy systems, and high stakeholder scrutiny, selling into one - and scaling across - requires more than a great pitch.
Donald MacDonald, MD (Head of Group Data Office) at OCBC, has been at the center of the bank’s digital and AI transformation. In this conversation, he pulls back the curtain on how banks evaluate technology, what AI vendors often get wrong, and what it actually takes to go from proof-of-concept to full rollout.
Q: How do you decide whether to build, partner, or buy when it comes to new technology?
Donald: Over the last 7 to 8 years, OCBC has thoughtfully evolved from being primarily a "partner shop" to investing heavily in internal builds. With strong in-house engineering talent today, we take pride in what we can develop ourselves - though we remain open to working with external vendors when there's a strong fit and clear value-add.
That said, we still partner and buy when it makes sense. We apply a structured evaluation framework. For AI solutions, we weigh four main factors:
Total Cost of Ownership (TCO): We closely assess whether the solution justifies its price not only in licensing or subscription fees, but also in terms of internal resourcing, integration effort, and long-term maintenance. If it's a thin layer over tools we could easily build ourselves, it won’t pass muster.
Customization Needs: Some solutions require deep integration with OCBC’s internal data, processes, and architecture. If significant customization is required to make the product work effectively in our environment, it’s usually more efficient - and secure - for us to build it internally.
Vendor Differentiation: We look for vendors who bring something genuinely unique to the table - whether that’s proprietary algorithms, access to high-quality training datasets, or capabilities that would take us substantial time to replicate.
Integration Effort: We operate in a tightly regulated environment with multiple layers of infrastructure. The easier a solution is to integrate with our stack - both technically and from a compliance standpoint - the more attractive it becomes. Tools that require heavy internal changes, lack APIs, or create risk silos often get deprioritized.
M&A is relatively rare. Our focus is to either build internally or partner strategically.
Q: What are the hidden trade-offs when partnering with AI or SaaS vendors?
Donald: Three things often get overlooked:
Data Complexity: Vendors often underestimate the challenge of plugging into our data. The application might look slick, but without deep understanding of our data, it’s ineffective. That complexity still falls on us.
Explain-ability and Transparency: In banking, we must explain how our AI systems work, especially to regulators. Many vendors offer black-box solutions, which doesn't fly in our environment.
Model Monitoring: We monitor our models daily for drift and performance. External AI tools often don’t integrate with our monitoring systems, which creates risk and operational friction.
Q: What are the most common mistakes vendors make when trying to sell into banks?
Donald: Two stand out:
Generic Pitching: Vendors often come in with a broad, high-level pitch. But our teams live and breathe these processes—whether it's AML, credit, or compliance. If you don’t understand the details, we lose trust fast.
Not Knowing the "As-Is": We publicly share what we’ve built. Yet, vendors still pitch us solutions we've already deployed. That tells us they haven’t done their research.
Q: Let’s say a vendor lands a POC. What should they know to make it successful?
Donald: Treat the POC like a final exam. If it fails, there’s no next step.
The best vendors don’t just deliver on the scoped use case - they proactively identify new opportunities, sometimes turning the engagement into a co-development effort. These are the companies we want to work with long-term.
A great POC makes us want to champion the vendor internally.
Q: How does a vendor move from a single-use case to broader rollout across the bank?
Donald: We often start with a single team or department. But if that goes well, we showcase the solution to other business units and subsidiaries - like Bank of Singapore or Great Eastern.
A great example is Velotix. They started with a small use case around access management. But they listened, adapted, and eventually expanded into data lake governance, BI platforms, and more. That kind of curiosity and flexibility made it easy for us to roll them out across the group.
Q: Is it important for vendors to engage with multiple stakeholders in the bank
Donald: Absolutely - but it depends on what you're selling. Enterprise-wide platforms will require buy-in from many stakeholders. Department-specific tools might be more focused.
Regardless, it’s critical to build relationships with the technology architecture team. They're the ones who define the approved tech stack. If you’re not on that list, you won’t scale.
Any final thoughts?
Donald: Do your homework. Be specific. Treat the POC as your shot to prove value. And most of all, show us you’re willing to adapt and grow with us. That’s what separates a one-off project from a long-term partnership.