Buying, configuring and building are not competing ideologies. They are different ways to meet an operating requirement. Most firms should compare them against the same workflow, acceptance evidence, total commitment and ownership needs.
A financial services firm considering AI may face three broad choices: buy a finished product, configure existing tools around its workflow or build something more specific.
The labels can be misleading. A product may still require configuration, data work and operating change. A custom workflow may rely heavily on existing platforms. The useful decision is which combination reaches the required result with an acceptable level of cost, control and dependence.
The comparison should begin with the same documented workflow and the same evidence of success.
When a product may be the sensible choice
A product can be attractive when the workflow is common, the required features are mature and the firm is willing to adapt some of its process to the system.
The vendor may provide ongoing product development, support, security documentation and integrations that would be costly to recreate independently.
The evaluation still needs to examine fit. Can the product use the firm's authoritative information? Does it support the required permissions and review? How does it handle an unsupported exception? What information does the vendor retain, and how can the firm leave if the product no longer fits?
When configuration may create the best balance
Configuration uses approved platforms while adapting the workflow, instructions, integrations, permissions and user experience to the firm's needs.
This can work well when the underlying capability already exists but the value depends on connecting the right information and reflecting how the team actually operates.
The firm avoids rebuilding commodity infrastructure while retaining more control over the process. The main questions become how much customization the platform supports, who will maintain the configuration and what remains dependent on the provider or platform.
When a custom build may be justified
A more specific build may be appropriate when the workflow is materially different, creates competitive value, requires unusual integrations or cannot be handled responsibly within available products.
Custom work gives the firm more influence over the design. It also creates responsibility for testing, security, documentation, support, model or vendor changes and the people needed to maintain it.
The business case should explain why the distinct requirement is valuable enough to own. Custom should not be a default response to a process that has not yet been defined.
Compare the complete operating model
The purchase price or build fee is only one part of the decision.
Compare implementation work, licences and usage, integration, data preparation, testing, staff time, support, future changes and exit. Identify which responsibilities stay with the vendor, implementation partner and internal team.
The Bank of England and FCA's 2024 survey found that a third of reported AI use cases were third-party implementations and identified increasing concern about dependency on external providers. That does not make third-party tools unsuitable. It makes ownership, concentration and exit questions part of the decision.
Use the awkward case to test fit
Give each option the same representative task and the same difficult example.
For onboarding, that may be a missing document, a client with an unusual ownership structure or information that conflicts with an earlier record. For reporting, it may be a late file, a revised template or a figure that needs explanation rather than automatic inclusion.
Observe what the system does, what the user sees, how evidence is presented and what must be completed manually. This often reveals more than a feature list.
Decide what the firm wants to own
Some firms want a managed capability with a provider responsible for most technical operation. Others want administrator access, portable configurations and internal staff able to change the workflow.
Neither model is universally better. The agreement should make the chosen model clear, including documentation, intellectual property, data access, credentials, support, export and transition arrangements.
A firm should not discover after launch that an important workflow depends on one person's account or knowledge that was never transferred.
Use the same questions for every option
Fit
Can the option handle the real workflow, information, users and exceptions?
Control
Are permissions, review, records, retention and human responsibility clear?
Commitment
What are the implementation, recurring, internal and future-change costs?
Dependence
Which vendor, platform, person or proprietary component does the workflow rely on?
Ownership
What access, documentation, configuration and transition capability will the firm retain?
What should drive the sourcing decision?
Choose the approach that meets the defined operating requirement with the clearest acceptable commitment and ownership model.
A common product may be sufficient. A configured workflow may create the right balance. A distinct capability may justify custom work. The workflow and evidence should decide.
Halyard helps financial services firms assess available options without beginning with a preferred tool. We define the requirement, compare the practical routes and implement the approved solution inside the firm's operating environment.
Related Halyard resources
Further reading
Founder of Halyard, an AI implementation company helping financial services firms find and implement practical AI safely.