AML Transaction Monitoring Software: Build, Wrap or Buy
The question that decides it is what your finding actually says.
On this page
The question that decides it is what your finding actually says. If it describes governance, tuning evidence, data quality or alert handling, keep your vendor scenario library and build only the layer around it, which commonly lands at $140,000 to $220,000 and is the recommendation we give most often. If it describes typologies your engine genuinely cannot see, a first release runs $100,000 to $240,000 in 14 to 20 weeks and a full platform $280,000 to $700,000 across 9 to 18 months in Digital Heroes delivery experience. Most institutions reading this have a governance problem and should not replace detection.
When is off the shelf genuinely the right call here?
Buy the engine. That is the starting position for almost every institution in this category, and the only real question is which one and how much you build around it.
If you are a community bank or credit union with conventional retail and commercial products, Verafin is genuinely strong for that profile and brings cross institution context a single institution cannot assemble on its own. Your examiner has seen it before, which has more value than people admit when you are explaining your programme under pressure. NICE Actimize and Oracle Financial Crime and Compliance Management ship deep scenario libraries and are the conservative, examiner familiar choice at larger scale, and if you can absorb the implementation they are defensible selections. Feedzai and Hawk bring more modern detection approaches, and choosing one shifts the burden onto explainability and model validation, which is real work rather than a reason to avoid them.
Buying is right whenever your product set is conventional. Anti money laundering (AML) typologies for a bank doing deposits, cards, wires and small business lending are well understood and already encoded in every serious vendor library. Rebuilding structuring, rapid movement of funds and unusual wire corridor scenarios from scratch buys you nothing except the obligation to validate them yourself, forever.
Replacing a validated scenario set you did not need to replace is the most expensive mistake in this category, and it is made most often by institutions who read a governance finding as a detection finding. The two look similar on an examination page. One costs a few hundred thousand to fix and the other costs a multiple of that plus a year of parallel running.
When does a custom build actually pay off?
Building detection makes sense in a narrow set of circumstances, and it is worth being precise about them because the category attracts wishful scoping.
The first is a product set no vendor library covers. If you are a payments business, a marketplace, a crypto exchange or a lender with a genuinely unusual flow of funds, the scenarios that matter to you are not in anyone's shipped library and the vendor will quote you configuration work that amounts to a build with worse economics and no source code.
The second is data that no vendor can reach. Monitoring is only as good as the entity resolution underneath it. If the same customer exists as three identifiers across your core, your card processor and your digital channel, every scenario is evaluating a fragment. That layer is yours to build regardless of which engine you run, and institutions who skip it end up tuning thresholds against a picture that was never complete.
The third is governance you cannot evidence. When an examiner asks why a threshold sits at nine thousand five hundred rather than nine thousand, the answer needs a rationale, an approver, a date, and the testing that supported it. Most engines store the current parameter value. Very few store the argument. That gap is buildable and it is what most findings are really about.
Notice that only the first of those three is a reason to replace detection. The other two sit around whatever engine you run, which is why the wrap is the common answer.
How do they compare on the things that matter in this industry?
- Scenario coverage. Vendor libraries win decisively for conventional products, and lose entirely for flows nobody else has. Judge this by writing down your five highest risk typologies and asking the vendor to demonstrate each one against your data, not against a demonstration environment.
- Parameter governance. Ask any vendor to show you, for a single threshold, the current value, every previous value, who changed it, why, and what testing supported the change. This is where bought engines are commonly thin and where examiners are commonly focused.
- Historical replay. Above and below the line testing means running a proposed parameter set across last year's transactions and comparing outcomes. If the engine cannot replay history without disturbing production alerts, you cannot evidence tuning, and you will be arguing from intuition.
- Alert disposition quality. Free text closure notes are the norm and they are close to useless a year later. Structured dispositions with a controlled vocabulary are what let you show that a scenario is producing noise rather than that your analysts are lazy.
- Data portability. Your alert history, dispositions and parameter history are the record of your programme. Establish in writing how you extract all three, in full, in a form you can read without the vendor.
- Per seat and per volume economics. Engines priced per transaction punish growth and engines priced per analyst punish staffing up after a finding, which is exactly when you need to staff up.
What does total cost of ownership look like at your scale?
A first release covering the customer and transaction data layer with entity resolution, scenario execution with parameter versioning, and alert triage with structured dispositions runs $100,000 to $240,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding customer segmentation, historical replay for above and below the line testing, tuning evidence packs, model documentation and integration with case management and filing runs $280,000 to $700,000 across 9 to 18 months.
The wrap, meaning you keep the vendor scenario library and build the data layer, entity resolution, parameter governance and triage around it, commonly lands at $140,000 to $220,000. In a worked example we have priced, the same institution that would spend around $220,000 on a first release with its own execution engine lands closer to $165,000 keeping the vendor library, and delivers the same answer to the examiner.
Phase two, historical replay and testing, is typically $80,000 to $170,000. Phase three, segmentation, tuning evidence packs and model documentation, commonly runs $70,000 to $160,000.
Set that against what you already spend. The engine subscription continues in the wrap scenario, which is the point. What changes is the consultancy line: institutions in this position routinely pay external model validation and remediation firms sums that would have funded the governance layer twice over, because the evidence has to be assembled by hand each time rather than produced by the system.
What does the hybrid look like, and when is it the honest answer?
The hybrid is the default recommendation here, not a compromise. Keep the engine, build the layer.
Concretely, that means the vendor keeps doing detection and you build four things. A transaction and customer data layer that assembles a complete, timely picture across your source systems. Entity resolution so one customer is one customer regardless of which system generated the identifier. A parameter governance layer over the vendor's settings that records value, rationale, approver, date and supporting testing for every change. An alert triage interface with structured dispositions your analysts can complete honestly in the time they have.
This is the right answer whenever your finding is about governance, data quality or alert handling, which is the majority of findings. It is also the right answer when your product set is conventional but your data estate is messy, which is extremely common after an acquisition.
It is the wrong answer in one case: where the engine genuinely cannot see your typologies. Wrapping a blind engine in excellent governance produces a well documented failure to detect anything, and no examiner is impressed by that. Establish which situation you are in by testing scenarios against your own data before you commit, not by reading a capability matrix.
Which should you choose, by operator size and stage?
A community bank or credit union with conventional products should buy Verafin or a comparable engine and build only the data quality and tuning evidence layer around it. The build here is $140,000 to $220,000 and it is the whole project.
A mid sized institution running NICE Actimize or Oracle with a governance finding should wrap, not replace. Read the finding again with your financial crime lead and mark each item as detection, governance, data or handling. If detection is a minority of the items, replacement is not your answer.
A payments business, marketplace or lender with unconventional flows should build detection, and should expect the full range: $100,000 to $240,000 for a first release and a phased path toward $280,000 to $700,000 as segmentation and testing arrive. Budget the entity resolution line generously, because it is where these projects overrun.
An institution that has recently acquired another bank sits in its own category. The monitoring question and the data question arrive together, and the data question is larger. Two cores, two customer identifier schemes and two sets of historical alerts do not become one engine problem, they become an entity resolution problem with a deadline attached. Wrap whichever engine survives the integration, build the data layer properly, and do not let a vendor selection process absorb the year that should have gone into reconciling customers.
A firm that has just received a finding, at any size, should spend the first month scoping rather than buying. The pressure to announce a remediation programme is real and it produces expensive decisions. Fourteen to twenty weeks to a first release is not slow when the alternative is a two year replacement of something that was working.
When the shortlist is down to two and you need a tiebreaker, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- Technology 'Leaders' grow revenue at more than twice the rate of 'Laggards'; laggards surrendered 15% in foregone annual revenue in 2018 and stood to miss out on as much as 46% in revenue gains by 2023 if they did not change their enterprise technology approach. Based on a survey of more than 8,300 organizations across 20 industries and 20 countries. Source: Accenture (2019) →
- One in four US employees report lacking career advancement opportunities; 48% of employees who participated in mentorship programs report high job satisfaction versus 29% of non-participants, and access to advancement opportunities ranges from 33% at organizations under 10 employees to 74% at those with 1,000+. Source: Gallup (2025) →
- Criteo's Global Commerce Review found retail apps convert at 18% versus 4% on mobile web (roughly 4.5x), and travel apps convert at 20% versus 6% on mobile web (about 3.3x). Source: Criteo (2017) →
Frequently asked questions
Should we replace NICE Actimize or build around it?
Build around it in most cases. Read your finding and mark each item as detection, governance, data quality or alert handling. If detection is the minority, replacement solves a problem you do not have while creating a validation obligation you did not previously carry. Keeping the scenario library and building the data layer, entity resolution, parameter governance and triage around it commonly lands at $140,000 to $220,000, which is roughly a third of a replacement, and it addresses what the examiner wrote rather than what the project team found interesting.
Is Verafin enough for a community bank?
For a community bank or credit union with conventional retail and commercial products, generally yes. It covers those typologies, brings cross institution context a single institution cannot build, and your examiner has seen it before. What it does not do for you is fix identifiers that disagree across your core, card processor and digital channel, or produce the parameter history and testing evidence an examiner asks for. Those sit around any engine. Buy the engine, build the layer, and do not confuse the two decisions.
What does it cost to switch monitoring vendors?
The licence difference is the least of it. Budget for extracting alert history, dispositions and parameter history in a readable form, mapping your data into a new model, and running both engines in parallel for at least two quarters so you can show continuity of coverage. Institutions consistently underestimate the parallel period, and it is the part examiners ask about. Before signing anything, get the export format for those three record types in writing, because a monitoring history you cannot read without the outgoing vendor is not a record you control.
What if our vendor changes its pricing model?
The exposures that hurt are per transaction pricing, which punishes growth, and per analyst pricing, which punishes staffing up after a finding at exactly the moment you must. Neither is a reason to build detection. The practical protection is to keep the data layer, entity resolution and alert history in systems you own, so the engine becomes a component you can renegotiate or replace rather than the place your entire programme lives. Institutions that build that layer report a very different tone in renewal conversations.
How long before the new monitoring is running in production?
Fourteen to twenty weeks for a first release, with the data layer and entity resolution taking the first half of that because everything downstream depends on them. A wrap is faster, commonly ten to fourteen weeks, since scenario execution stays with the vendor. Expect at least one full quarter of parallel running before you retire anything, and plan a tuning cycle inside that quarter so the first above and below the line test happens while both systems are available for comparison.
Can we keep our engine and build only tuning evidence?
Yes, and it is the most common shape we deliver. A parameter governance layer sits over the vendor's settings and records the current value, every previous value, the rationale, the approver, the date and the testing that supported the change. Add historical replay so a proposed parameter set can be run across last year's transactions without disturbing production alerts. That combination is what turns a tuning conversation from an argument into a document, and it is a fraction of the cost of replacing detection.
What is the biggest cost driver in a monitoring build?
Entity resolution, consistently. Scenario logic is well understood and estimable. Reconciling identifiers across a core banking system, a card processor and a digital channel, then deciding what to do with the cases the rules cannot settle, is where the hours go. In a worked example we have priced, entity resolution across three identifier sources came to $38,000 against $44,000 for a full scenario execution engine with parameter versioning. Count your identifier sources before you budget anything else.
What does it cost to run each year once it is live?
Budget continuing engineering at roughly a fifth of the build cost in year one and closer to a tenth thereafter, spent on new typologies, source system changes and examination requests rather than on a support retainer. Your engine subscription continues in the wrap scenario, which is intended. The line that usually falls is external model validation and remediation consultancy, because the evidence a validator asks for is produced by the system rather than assembled by hand each cycle.
How many people should be working on my software project?
A typical $40,000 to $150,000 build runs on three to five people: a technical lead, one or two developers, a designer, and someone owning QA and project communication, often as overlapping part-time roles. More bodies do not make software arrive faster; past a point they slow it down with coordination overhead. The question that matters more than headcount is whether one named senior engineer is accountable for the outcome.
We run everything on Airtable and spreadsheets. When is it time to go custom?
The switch usually makes sense when you hit one of two walls: Airtable's record caps (125,000 records per base on the Business plan) or logic the tool cannot express, like multi-step approvals with conditional pricing. There is also a simple cost signal: 25 people on Business at roughly $45 per seat per month is about $13,500 a year, forever, for a tool you are already fighting. Custom is worth it when the workflow is core to how you make money; for peripheral processes, staying on Airtable is the right call.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
Will custom software work with the tools we already use, like QuickBooks and Stripe?
Yes, and this is one of custom software's genuine advantages: QuickBooks, Stripe, Shopify, and most mainstream business tools publish documented APIs built for exactly this. Expect each standard integration to add one to two weeks of build time, and be suspicious of any quote that lists five integrations without asking what data flows in which direction. The hard cases are legacy systems with no API, which is a question to raise in discovery, not in week nine.
What is a discovery phase, and is it worth paying for separately?
Pay for it, and treat the output as yours. A discovery phase runs two to three weeks, typically 5 to 10% of the eventual build budget, and produces a written scope, wireframes, and a fixed quote you can take to any vendor, including a competitor of the agency that wrote it. Skipping it is how projects end up quoted from a two-paragraph email and delivered at twice the price.
Should I ask for a fixed price or pay the agency hourly?
Fixed price for the first version, hourly or retainer for what comes after launch. A fixed-scope, fixed-price V1 puts the estimation risk on the agency, which is exactly where you want it while trust is unproven; hourly billing on an unscoped greenfield build is a blank check. After launch, flip it, because maintenance and small features arrive unpredictably and fixed-pricing every ticket wastes everyone's time.
What are the biggest mistakes first-time software buyers make?
Choosing the lowest bid, paying more than 30-40% upfront instead of on milestones, skipping a written specification, and having no maintenance plan for after launch. The most expensive of the four in Digital Heroes rescue projects is the missing spec: without written acceptance criteria, done becomes an argument instead of a checklist, and every disagreement resolves in the vendor's favor. Fix those four and you have avoided most of the ways these projects fail.
What should I prepare before contacting a software development agency?
A one-page brief beats a 40-page requirements document: the business problem in plain words, who will use the system, the 5 to 10 workflows it must handle, the tools it must connect to, and your budget range and deadline driver. You do not need wireframes, a specification, or technical vocabulary; producing those is the agency's job during discovery. Stating a budget range up front is the single best move, because it gets you honest scoping instead of a quote engineered to win the meeting.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Maya.
Senior QA Engineer · Delhi · 1 post on the site
Published · Last updated .
