Should You Build Your Own Document Fraud Detection? 

Banks and non-bank lenders often consider trying to solve document fraud in-house, using metadata and LLM-based solutions. 

On the surface, “Building” looks like a win for cost and control. It seems logical – you know your customers, your risk appetite, and your tech stack. However, the path from a successful Proof of Concept (PoC) to a production-grade document fraud engine is often longer, more expensive, and more data-dependent than most institutions anticipate.  

To make a truly informed decision, you must look past the initial “build” phase and into the scientific, technical and operational reality of long-term detection effectiveness. 
 
Building your own document fraud detection isn’t just expensive – as a Bank or Lender, it’s near impossible to do well long term and at scale. 

You’re fighting a network. Alone. 

Document fraud in lending is not committed by lone operators. It is an organised, networked, and increasingly commercialised criminal ecosystem. Fraud rings share techniques, templates, and tooling. They test their forgeries across multiple institutions, sometimes deliberately cycling through smaller lenders first to refine their methods before targeting the major banks. 

When fraud hits your organisation, you see one data point (if you catch it). You investigate, you adapt, you update your detection solution. But by the time your internal team has diagnosed the pattern and tested and deployed a fix or change, those same fraudsters have likely moved on or are already testing three other lenders who have no idea what you just learned. This is happening all of the time, every single day. 

A fraudster who fails at one institution doesn’t stop, they learn and iterate. The question is whether your detection capability moves faster than they do, and whether it does so in isolation, or with the benefit of the entire industry’s experience. 

This is the foundational problem with an in-house approach: your signal is limited to your own applications. A non-bank lender processing 5,000 loan applications per month has a fundamentally different fraud visibility window than an industry-wide platform aggregating patterns across billions of dollars of lending. The mathematics of detection simply don’t work in your favour when you’re operating alone.

The power of shared signals and why you can’t replicate them 

The most powerful asset in fraud detection is not a better algorithm. It is data breadth. Specifically: the ability, without storing PII, to recognise a fraudulent document or entity that has been seen before, perhaps by a different lender, perhaps in a different industry (like insurance), in a different state, or using a slightly different document layout. 

A common platform that is used industry-wide accumulates something that no single institution can build organically: a cross-lender fraud memory. In response to a detection event and confirmed fraud case, key suspicious patterns gets added into an intelligence layer that benefits every participant. A payslip created using a template from a large payroll software provider might be flagged instantly not because your models have seen it, but because 100s of other payslips have been processed from that employer, and the employer doesn’t actually use that software. 

This is network intelligence and it compounds over time. The longer such an industry utility has been operating, and the more institutions contribute to it, the richer and more sensitive the detection capability becomes. A lender building in-house starts from zero. They must earn every data point through their own loss experience, which is precisely the kind of experience you want to avoid. 

What an isolated, in-house system can’t know

• That a specific ABN, Accountant, Application or even Author has been used in fabricated documents across six other lenders in the past 90 days 
• That a new document template is in active circulation despite appearing visually authentic 
• That a cluster of applications sharing similar metadata fingerprints constitutes an organised crime ring, not isolated incidents 
• A new fraudulent document tactic has emerged, which was previously not commonplace (such as using LLMs to alter documents) 
• A new AI-generated document manipulation technique is currently being stress-tested across the lending industry 

The modus operandi doesn’t stand still …

it requires constant investment, research and development 

Five years ago, the document fraud challenge was totally different. Fabricated bank statements looked visibly poor. Payslips had obvious errors, such as spelling mistakes. An understanding of metadata was less commonplace than it is today, so fraudsters often left a data-rich trail for fraud detection. 

Today, the landscape has categorically changed. Desktop tools are all AI-enabled, helping the laziest fraudsters produce high-quality documents. Generative AI has rapidly evolved, putting extraordinarily capable document creation tools in the hands of both everyday liar-loan applicants as well as sophisticated fraud rings.  

If you’re working at a Bank or Lender, you often learn about new fraud techniques through write-offs or tip-offs: both happen after the fact, once the loans are settled and is on your book. 
 
By the time these examples then make it to your internal engineering team to review, determine a new change, test for performance, check the false positive rate, ship to production and then train or operationalise the new alert, months have passed and substantial losses or money laundering has occurred. Specialised utility providers are completely focussed, streamlined and built to react quickly to new MOs as they arise.

Consider what responding to a new fraud vector requires internally: a forensic analyst to characterise the new technique, a data scientist to model the detection signal, an engineer to implement the feature, a QA process to validate it and ensure false alerts won’t bombard your operational team, and a deployment pipeline to release it – all while your institution continues to be exposed. 

The technology doesn’t stand still either 

As fraud tactics have continued to evolve, so too does technology. The sophistication and data in a solution today is completely different to what was required even just two or three years ago. 

Today, document fraud detection involves a layered technology stack that itself is evolving rapidly. Effective detection requires capabilities across computer vision, natural language processing, OCR, metadata analysis, file forensics, network graph analysis for identifying connected entities, and increasingly, machine learning and AI techniques to detect AI-generated content. 

And beneath each of these, there is an underlying complexity in dealing with documents that are redacted, split, merged, screenshots and photographs. Each of these presents very real challenges with false alerts or missed fraud, that technology needs to be able to cater for and handle. 

Each of these domains has its own research frontier, its own open-source community, and its own specialist talent pool. For example: 

• Analysis of pixels to determine tampering of documents taken as photographs or images; or to detect the use of artificial intelligence models 

• PDF/image metadata and structure analysis, as well as handling exceptions such as redacted PDFs, split or combined PDFs 

• Building, maintaining and utilising network link analysis and pattern data to identify emerging threats, without impacting privacy or storing Personally Identifiable Information (PII) 

• Identifying and deploying new models and rules based on real-world fraud investigation outcomes through data analysis, arrear/delinquency reviews, user feedback and event reporting. 

• Deploying, maintaining and evolving content analysis capabilities such as computer vision models, OCR and large language models. 

• Design and continued development of user interfaces to aid investigators in making a quick decision, to spend less time searching documents manually 

• Designing, building and maintaining highly resilient, reliable, secure and privacy-friendly technology that is always maintained and up-to-date 

• Keeping pace with all of them simultaneously, meeting operational targets for alerts, false positive rate and false negative rate, while also maintaining your core lending technology, is operationally unrealistic for any single institution. 

Utility providers have SMEs and strategists that are focused on ensuring the best technologies and techniques are used, with maximum value return to the customer. These platforms constantly innovate and mature their platforms, as opposed to the typical bank/non-bank project cycle, which typically follows the below: 

Year 1  Foundation build and the PoC trap 

In modern software development, building a limited-scope (sub-optimal) PoC is no longer the hurdle it once was. With accessible LLMs and basic metadata libraries, an internal team can often reach a 30%-50% detection rate on known, historical fraud samples within a few months.  

This creates a “False Peak” of confidence. Stakeholders see the initial detections and assume the remaining 70%-50% is just a matter of “tuning” that can take a few months to close. 
 
In reality, that remaining percentage – and the critical management of the False Positive Rate (and impact on good customers and operations) is where the complexity grows exponentially. 

Year 2  Model maturation and the first major gaps 

ML models begin to mature on your own data. Data gaps exposed on a regular basis that require closing. Solution not able to be scaled to other products, channels or geographies as still fitting to initial use case and true learnings emerge about the complexity of the challenge. 

Year 3  Resource retention crisis 

Pressure to focus resources on other projects. Model drift occurs, technical debt accumulates and false negatives (fraud that should have been detected) create pressure. 

Year 4  The rebuild conversation 

Leadership asks whether the $4 – 6M invested over three years has delivered better outcomes than a specialist platform would have. The honest answer is usually no. Other organisations have progressed and now you are on the back foot and a prime target for fraud.

Can’t you just use LLMs and agents to detect document fraud? 

Large Language Models (LLMs) are a powerful tool that certainly play a useful role in the fight against document fraud. They are not, however, a silver bullet. Their ability to process large documents and intuitively find meaning in text is very helpful, but they have significant capability and running cost limitations. 

Fortiro’s Research & Development team consists of specialist, PhD-qualified experts who provide deep expertise in different aspects of AI and fraudulent document detection. Key limitations exist such as: 

• Poor fine-grained visual discrimination; inability to recognize specific fonts or typographic styles accurately. 

• Inability to reliably detect or remove low-level artifacts; risk of introducing new generative artifacts. 

• Limited built-in capability with instead relies on 3rd party tooling or additional services to provide enough in-depth analysis 

The true measure of a fraud solution isn’t just “Can it catch fraud?” but “Can it catch fraud without breaking the customer experience?” In a lending environment, you are constantly balancing two opposing forces: 

• False Negatives (FN): Missing a fraudulent document that results in a bad loan and a total loss. 

• False Positives (FP): Flagging a legitimate document as fraud, leading to manual reviews, customer friction, delays, and abandoned applications. 

Achieving a high “True Positive” rate while keeping False Positives at a negligible level requires more than what LLMs can deliver; it requires massive, diverse capabilities (that can include LLMs) and input data test set that covers thousands of document variations. For an isolated lender, its system only learns from its own mistakes. If you process 5,000 loans a month, your model’s “experience” is a tiny fraction of what an industry-wide platform sees. 

The Precision Problem: A system that catches 100% of fraud but has an 80% False Positive rate will paralyse your operations team. Conversely, a system with 0% False Positives that misses half of the sophisticated fraud is merely expensive “security theatre.” Optimising for the “ideal” zone of low FPs and high TPs takes extensive capabilities, years of tuning and millions of data points.

Banks aren’t built for the demands of modern fraud detection 

There is a structural tension at the heart of every in-house fraud solution build that rarely surfaces in the initial business case and almost always surfaces painfully two or three years later. It comes down to how banks and large lenders are organised to deliver technology, and why that model is fundamentally incompatible with the operational demands of effective fraud detection. 

The dominant model for technology delivery in financial institutions follows a familiar rhythm: a capital-funded project is stood up, a team is assembled, a solution is built and deployed, and then the system transitions to business-as-usual operations, typically handed to a smaller, lower-cost team with a mandate to keep the lights on rather than to innovate. This model works well for core banking systems, payment rails, and customer portals. These are platforms where stability is the goal. 

Document fraud detection is the opposite of this. It is a domain where standing still is functionally equivalent to moving backwards. The moment your detection capability stops actively evolving – the moment it enters BAU – it begins to decay relative to the threat landscape.  

The project team that built your fraud detection capability understood the domain deeply. The BAU team that inherited it does not. These are not the same job, and fraud detection requires the former, permanently.

This creates a practical problem that plays out with striking consistency across institutions that have attempted the build. The initial project is well-resourced and delivers a credible first version. Then the system goes live, the project closes, headcount reduces, and the domain expertise begins to walk out the door. What remains is a capable-enough system frozen at the state of the threat landscape circa its launch date. 

WHY “BAU” KILLS A FRAUD DETECTION SYSTEM

• Model retraining happens too irregularly, if at all, rather than continuously as new fraud signals emerge 

• New fraud techniques go undetected until they cause material losses or are surfaced in an investigation, at which point a project is re-initiated to respond 

• Alert thresholds drift out of calibration as application volumes and mix change, generating false positive rates that quietly erode the team’s trust in the system 

• Regulatory expectations triggering remediation work that competes with other BAU priorities 

• The institutional knowledge of why specific rules and models were designed the way they were gradually disappears as team members turn over 

The deeper issue is incentive alignment. A BAU operations team is typically measured on cost efficiency, system availability, and Service Level Agreement (SLA) adherence. None of these metrics reward the proactive investment in detection capability that fraud defence genuinely requires. A specialist utility provider, by contrast, is commercially measured on detection performance. The incentive to continuously improve is structural, not aspirational. 

Regulators expect fraud controls to be demonstrably effective and not just present. A system that was state-of-the-art at launch, but hasn’t been materially updated in 18 months, will struggle to satisfy that expectation during an operational risk review. 

CAPABILITY DETECTION	IN-HOUSE BUILD	INDUSTRY UTILITY SAAS
Cross-institution fraud signal	✕  Your data only	✓  Full network visibility
Response time to new fraud MO	✕  Months	✓  Days or faster
Model training data volume	Manual/inconsistent	✓  Industry-wide
AI-generated document detection	✕  Requires dedicated R&D, as GenAI models are moving very quickly	✓  Continuously updated
Post-launch model evolution	✕  Decays to BAU, static controls	✓  Continuous improvement by design
Regulatory and compliance audit trails	Manual / inconsistent	✓  Built-in and standardised
Talent dependency risk	✕  High: key-person risk	✓  Strategic talent acquisition and retention of specialists
Time to first detection	✕  4 to 9 months minimum	✓  Days from integration
Cost at scale	✕  Fixed overhead regardless	✓  Volume- and capability-proportionate

What “build” actually costs 

The internal business case for building is often framed around software licensing costs avoided. It’s a misleading comparison. The total cost of a credible in-house capability extends well beyond engineering salaries. 

There is the cost of the fraud that occurs during the capability ramp-up period, a period typically measured in years, not months. There is the ongoing cost of false positives: legitimate applications declined or delayed because your models haven’t been calibrated against a sufficiently broad training set. 

There is the opportunity cost of engineering resources diverted from other priorities. And there is the reputational cost when – not if – a sophisticated fraud ring finds the gap in your self-built controls. 

A specialist utility provider has already absorbed these costs across its entire client base. The investment in research, talent, infrastructure, and model development is shared and the unit economics for any individual institution are fundamentally superior. 

The question is not “build or buy” but rather “compete or cooperate” 

Lenders compete fiercely on rate, product design, service quality, and customer experience. These are the dimensions that differentiate a lending business in the market. Document fraud detection is not one of them. No borrower chooses their lender based on the sophistication of its internal fraud controls. 

What document fraud detection does determine is whether you spend more on fraud losses or fraud avoidance. Fraud losses at sufficient scale erode margin, attract regulatory attention, and in extreme cases – compromise lending portfolios in ways that take years to unwind. This makes fraud detection critical infrastructure, and critical infrastructure is almost always better managed as an industry utility than as a duplicated internal capability across dozens of competing organisations. 

Lenders don’t build their own payment rails. They don’t run their own credit bureau. Their technology teams don’t develop their own anti-virus software. They don’t develop proprietary property valuation indices from scratch. These are shared utilities because the economics of duplication don’t make sense. Document fraud detection belongs in the same category. 

The institutions that consistently outperform on fraud detection are not the ones that built the most sophisticated internal capability. They are the ones that recognised fraud as a network problem, and chose to be part of the network solution, embracing document fraud along-side other capabilities both internal and external.

There is also a regulatory dimension that is only becoming more significant. Prudential expectations around operational risk management, combined with increasing regulatory scrutiny of responsible lending compliance, create an environment where documented, auditable, and independently validated fraud controls are not optional. 

The case for building in-house closed five years ago 

There was a moment – perhaps a decade ago – when a well-resourced major bank could plausibly argue that building proprietary document fraud detection was the right call. The technology was less mature, cloud was not widely adopted, specialist vendors were fewer and less proven, and the data network effects of shared platforms were less established. 

That moment has passed. The AI-driven acceleration of fraud sophistication, the growing regulatory expectations around fraud controls, and the demonstrated compounding advantage of cross-institution intelligence networks have collectively closed the case for build-your-own. 

The question for any lender evaluating this decision is not whether they can build something. They can. The question is whether, in 18 months’ time or even a year’s time, what they built will be better than what the industry network has become and not what it was 12 months ago. The evidence consistently says no.