For security teams at regulated fintechs, choosing between building a tool in-house and buying an existing solution is rarely straightforward. Building offers flexibility and control, while buying brings established capabilities and vendor support. But both come with costs, risks and long-term responsibilities that aren't always obvious upfront. So how do you decide which approach makes sense? In this blog, we share how PayGlocal approaches the build vs buy decision in cybersecurity, the five questions that guide our choices, and the lessons we've learnt from building and maintaining our own security controls.
Running security at a regulated fintech means meeting a bar set for a bank with the budget and headcount of a growth-stage company. At PayGlocal, we hold RBI authorisation as a Payment Aggregator - Cross Border - Inward & Outward (PA-CB-I&O) and as an Online Payment Aggregator (PA-O), so we answer to RBI, and comply with FEMA, PCI DSS and the DPDP Act. Our security team is a fraction of the size those expectations were designed around.
So every new requirement raises the same build vs buy question for our security tools: do we buy a product for this, or build it ourselves?
Neither default is safe. "Just buy the platform" can leave you paying for features you never use, while the controls the regulator cares about most go unaddressed. "Just build it with open source" can leave you with tools only one person understands, which nobody notices have stopped working. So we don't default. We decide, one control at a time.
Building software has never been easier. Mature open-source projects, cloud services and modern developer tooling mean a small team can stand up a working product, an internal tool or a dashboard in days rather than months. Building can start to feel almost free.
It isn’t. Getting something working is cheap. But it's quite a different story when you need to OWN it. For instance, someone still has to keep it running, notice when it breaks, update it when the systems around it change, and support the people who depend on it. Those costs don’t shrink just because the first version was quick to write.
In security, that ownership cost carries extra weight. A homegrown security tool also has to prove to an auditor that it works, and it has to keep up with attackers who keep getting faster, as the gap between a vulnerability being disclosed and being exploited keeps narrowing. A small team can’t afford tools that look healthy on the outside but does not notice warning signs in the background.
At PayGlocal, every build decision has to pass five questions.
Running across all five is one more lens: business risk. Ask what it would cost if the data this control protects were exposed. The more sensitive that data, such as card details or national identity numbers, the higher the bar for building, and the stronger the case for proven, vendor-backed tools.
The first three questions tell us whether building makes sense. The last two tell us whether we can do it responsibly.
If the first three point to build and the last two have good answers, we build. Otherwise, we buy.
In practice there is often a third path: buy the platform for the heavy lifting, then build a thin layer on top for what only we need, such as custom detections or mapping evidence to RBI requirements. The vendor stays responsible for scale and uptime, and our team stays focused on the context no vendor will ever have.
This hybrid model is also defence in depth. A homegrown control is one layer among several, not the only thing standing between an attacker and your data. If it fails quietly, a bought layer is still watching, and the reverse is true too.
Imagine a scanner whose access key quietly expires. It can no longer see your cloud systems, so it reports zero issues, and zero issues looks like a clean bill of health. The dashboard stays green for weeks.
Silent failure is a real risk. Our own attack surface monitoring once looked complete while scans were quietly failing. We rebuilt it smaller and stricter: pinned versions so an update cannot change behaviour without us knowing, checks that the output actually makes sense, and an alert when a scan returns suspiciously little. A tool that fails silently is worse than no tool.
When we built credential exposure monitoring, most of the effort did not go into code. It went into runbooks, response playbooks and rules for how we handle what we find. Finding a leaked password is the easy part. Deciding who gets told, how fast, what gets reset and how the finding is stored is where the real work sits.
A good homegrown control also needs a feedback loop. Every finding teaches the team something: a rule that fires too often, a source it misses, a step in the response that is too slow. Feeding those lessons back into the tool is what makes it better over time, rather than just older.
Exposure data is also personal data. Under the DPDP Act, it needs the same discipline as any other processing: a clear purpose, limited access and a defined retention period.
They need a control that is designed well, operating and evidenced. A homegrown tool can meet that bar as well as any commercial product, if you treat it like a control. That means a named owner, change control, logs and a record of it running. If you cannot show those, you built a script, not a control.
Maintenance never ends. Documentation debt compounds. Every week spent building is a week not spent on something else. Budget for a build as honestly as you would for a licence, including the time to run it next year and the year after.
Good controls do not just satisfy auditors. They win business. Merchants, banking partners and enterprise customers all want proof that a payments provider takes security seriously, usually through detailed security questionnaires and due diligence reviews.
A control that is designed well, operating and evidenced answers those questions quickly and convincingly. At PayGlocal, the same evidence we prepare for regulators is what we put in front of partners. Building with audit-ready evidence in mind turns security from a cost centre into something that helps close deals.
We still buy, and in some areas we always will. At PayGlocal, anything that sits inline on production traffic, in the direct path of live payments, we buy. Anything that needs global scale and constant uptime, we buy.
In those areas, a vendor's scale, redundancy and dedicated engineering are exactly what we are paying for. No small team should try to replicate them.
Before you call a homegrown tool a control, make sure you can say yes to each of these.
Build vs buy is not a philosophy. It is a decision you make one control at a time, with honest answers about context, cost, ownership and evidence.
Buy what needs scale. Build what needs your context.
That is the line we draw at PayGlocal. Security leaders at fintechs and smaller regulated firms: where do you draw yours?
Why is build vs buy so hard for regulated security teams?
Running security at a regulated fintech means meeting a bar set for a bank with the budget and headcount of a growth-stage company. At PayGlocal, we hold RBI authorisation as a Payment Aggregator - Cross Border - Inward & Outward (PA-CB-I&O) and as an Online Payment Aggregator (PA-O), so we answer to RBI, and comply with FEMA, PCI DSS and the DPDP Act. Our security team is a fraction of the size those expectations were designed around.
So every new requirement raises the same build vs buy question for our security tools: do we buy a product for this, or build it ourselves?
Neither default is safe. "Just buy the platform" can leave you paying for features you never use, while the controls the regulator cares about most go unaddressed. "Just build it with open source" can leave you with tools only one person understands, which nobody notices have stopped working. So we don't default. We decide, one control at a time.
Why does build vs buy matter more now?
Building software has never been easier. Mature open-source projects, cloud services and modern developer tooling mean a small team can stand up a working product, an internal tool or a dashboard in days rather than months. Building can start to feel almost free.
It isn’t. Getting something working is cheap. But it's quite a different story when you need to OWN it. For instance, someone still has to keep it running, notice when it breaks, update it when the systems around it change, and support the people who depend on it. Those costs don’t shrink just because the first version was quick to write.
In security, that ownership cost carries extra weight. A homegrown security tool also has to prove to an auditor that it works, and it has to keep up with attackers who keep getting faster, as the gap between a vulnerability being disclosed and being exploited keeps narrowing. A small team can’t afford tools that look healthy on the outside but does not notice warning signs in the background.
What five questions decide build vs buy?
At PayGlocal, every build decision has to pass five questions.
- Is the problem shaped by our data or our regulator? Generic tools solve generic problems well. But detecting Indian identifiers such as Aadhaar or PAN in leaked data, or mapping a piece of evidence to a specific RBI clause, often needs logic no vendor has prioritised. If the problem is shaped by our context, that is a point for building.
- Would we use 15% of the product and still need a person to run it? Many security platforms are built for large enterprises. If we would switch on a fraction of the features and still need someone to operate it, we are paying for the licence and the headcount. The licence is not the real cost.
- Is there a mature open-source core we can build on? We rarely build from zero. A well-maintained open-source project with an active community gives us a tested foundation, and we add our own context on top.
- Who maintains it when the builder is unavailable? If the honest answer is one person, that is key-person risk. A tool nobody else can run is a liability waiting for a resignation letter.
- Will the auditor accept the evidence it produces? A tool that works but cannot prove it worked does not count as a control. If we cannot show an auditor clear, reliable evidence, we have not solved the problem.
Running across all five is one more lens: business risk. Ask what it would cost if the data this control protects were exposed. The more sensitive that data, such as card details or national identity numbers, the higher the bar for building, and the stronger the case for proven, vendor-backed tools.
When do we build, and when do we buy?
The first three questions tell us whether building makes sense. The last two tell us whether we can do it responsibly.
If the first three point to build and the last two have good answers, we build. Otherwise, we buy.
In practice there is often a third path: buy the platform for the heavy lifting, then build a thin layer on top for what only we need, such as custom detections or mapping evidence to RBI requirements. The vendor stays responsible for scale and uptime, and our team stays focused on the context no vendor will ever have.
This hybrid model is also defence in depth. A homegrown control is one layer among several, not the only thing standing between an attacker and your data. If it fails quietly, a bought layer is still watching, and the reverse is true too.
Four lessons from building
1. Open source is a great base, but you own its failure modes
Imagine a scanner whose access key quietly expires. It can no longer see your cloud systems, so it reports zero issues, and zero issues looks like a clean bill of health. The dashboard stays green for weeks.
Silent failure is a real risk. Our own attack surface monitoring once looked complete while scans were quietly failing. We rebuilt it smaller and stricter: pinned versions so an update cannot change behaviour without us knowing, checks that the output actually makes sense, and an alert when a scan returns suspiciously little. A tool that fails silently is worse than no tool.
2. The code is perhaps a third of the work
When we built credential exposure monitoring, most of the effort did not go into code. It went into runbooks, response playbooks and rules for how we handle what we find. Finding a leaked password is the easy part. Deciding who gets told, how fast, what gets reset and how the finding is stored is where the real work sits.
A good homegrown control also needs a feedback loop. Every finding teaches the team something: a rule that fires too often, a source it misses, a step in the response that is too slow. Feeding those lessons back into the tool is what makes it better over time, rather than just older.
Exposure data is also personal data. Under the DPDP Act, it needs the same discipline as any other processing: a clear purpose, limited access and a defined retention period.
3. Auditors look for control
They need a control that is designed well, operating and evidenced. A homegrown tool can meet that bar as well as any commercial product, if you treat it like a control. That means a named owner, change control, logs and a record of it running. If you cannot show those, you built a script, not a control.
4. Building is never free
Maintenance never ends. Documentation debt compounds. Every week spent building is a week not spent on something else. Budget for a build as honestly as you would for a licence, including the time to run it next year and the year after.
How do good security controls help win business?
Good controls do not just satisfy auditors. They win business. Merchants, banking partners and enterprise customers all want proof that a payments provider takes security seriously, usually through detailed security questionnaires and due diligence reviews.
A control that is designed well, operating and evidenced answers those questions quickly and convincingly. At PayGlocal, the same evidence we prepare for regulators is what we put in front of partners. Building with audit-ready evidence in mind turns security from a cost centre into something that helps close deals.
What we always buy
We still buy, and in some areas we always will. At PayGlocal, anything that sits inline on production traffic, in the direct path of live payments, we buy. Anything that needs global scale and constant uptime, we buy.
In those areas, a vendor's scale, redundancy and dedicated engineering are exactly what we are paying for. No small team should try to replicate them.
Control or script? A quick checklist
Before you call a homegrown tool a control, make sure you can say yes to each of these.
- It has a named owner, and a backup who can run it.
- Changes to it are reviewed and recorded.
- It keeps logs that show it ran and what it found.
- It alerts someone when it stops working or returns suspiciously little.
- There is a written runbook for what happens when it finds something.
- You can show an auditor evidence mapped to the requirement it serves.
- Someone else could run it next week if the builder were away.
Where we draw the line
Build vs buy is not a philosophy. It is a decision you make one control at a time, with honest answers about context, cost, ownership and evidence.
Buy what needs scale. Build what needs your context.
That is the line we draw at PayGlocal. Security leaders at fintechs and smaller regulated firms: where do you draw yours?
