Document intelligence and a configurable decisioning layer are the two foundational parts of any serious loan automation deployment. They're often discussed as if they're the same thing - or as if one makes the other unnecessary. Neither is true.
Document intelligence is about what you can pull out of a loan document and make sense of: recognising document type, locating fields, understanding structure, then analysing the result into decision-ready data - income normalised, bank statements turned into cash-flow signals like ADB and DSCR, tampering flagged, values cross-checked across documents. The decisioning layer is about what happens after that: routing applications on extracted values, applying your credit policy, managing human review, integrating with downstream systems, handling exceptions. Both layers matter. But they fail in different ways, and understanding the difference shapes how you evaluate platforms and set expectations for what automation can deliver.
The Document Intelligence Layer
Document intelligence refers to the AI/ML capabilities that turn document images or PDFs into structured, validated, analysed data. This layer has a few distinct components, each of which can fail independently:
Document classification - identifying what type of document this is (bank statement, payslip, KYC package, loan application). Seems simple; becomes complex when documents arrive in bulk without labels, when document types vary by jurisdiction, or when a single uploaded file contains multiple document types mixed together.
Extraction and analysis - locating and reading specific fields within the identified document type, then turning them into figures a credit decision can use: normalising declared income, deriving average daily balance and debt-service coverage from a bank statement, reconciling totals. This is where accuracy discussions happen. Extraction accuracy on clean, standardised documents tends to be high across most platforms. The divergence happens on documents that are degraded, handwritten, photographed, skewed, mixed-language, or from non-standard sources: faded passbooks, handwritten bank entries, photocopied KYC documents, payslips that don't follow a template. This is the paperwork US-built IDPs like Ocrolus, Rossum, and Hyperscience choke on, because they were tuned for pristine documents. Floowed reads and analyses it.
Validation and cross-document checks - confirming that extracted values are internally consistent, match expected patterns, and agree across the file. A valid bank account number has a specific digit format. A date of birth should precede the document date by at least 18 years. The income on the payslip should square with the deposits on the bank statement, and the name and ID across documents should match. Validation catches extraction errors, and cross-document checks catch the inconsistencies that signal fraud, before either passes silently downstream.
Confidence scoring - the model's estimate of its own extraction accuracy for each field. Well-calibrated confidence scores are essential for human-in-the-loop review: they determine which extractions route automatically versus which surface for human verification. Poorly calibrated confidence scores - where the model is confidently wrong - are a common failure mode.
The Decisioning Layer
The Decisioning Engine governs what happens once structured, analysed data exists. This layer includes:
Routing and policy logic - where does this application go based on its analysed values? A loan application with a debt-to-income ratio above a threshold routes to senior underwriting. A thin-file applicant routes to an alternative-data check. A KYC document with low extraction confidence routes to the compliance analyst queue. This logic needs to be configurable by the people who understand the credit policy - not hardcoded by engineers who implement it once and can only change it via a development ticket.
Human review queues - the structured interface where reviewers handle exceptions. Queue design matters: a well-designed queue shows the source document and extracted values side by side, highlights the specific fields flagged for review, provides clear accept/correct/reject actions, and logs decisions automatically. Poor queue design creates bottlenecks and inconsistent review decisions.
Approval hierarchies - who can approve what, at what thresholds, with what escalation paths. Loan approvals above certain amounts require a second sign-off. Exceptions outside normal credit parameters require escalation to a supervisor. These hierarchies need to be configurable as the business and the policy change.
Integration with downstream systems - once an application is processed and decisioned, data needs to flow into the systems that act on it: the loan origination system, the LMS, the core banking platform, the credit bureau. The quality of this integration - how reliably it transfers data, how it handles failures, how easy it is to maintain as downstream systems evolve - determines whether automation delivers its promised efficiency.
Audit trail - a complete log of every extraction, routing decision, review action, approval, and system integration event. In regulated lending, this log is not optional - it's the compliance evidence that auditors and regulators require. Platforms that don't provide field-level audit trails (logging exactly what was extracted, who reviewed it, what was changed) leave a compliance gap that manual processes or custom development have to fill.
Where Each Layer Fails
Understanding failure modes helps avoid buying the wrong layer of capability.
Document intelligence failures: Accuracy degradation on difficult documents is the most common failure mode. A platform that reads clean payslips at 98% accuracy may read faded bank statements at 82%. Confidence score miscalibration is a subtler failure: the model reports high confidence on incorrect extractions, which flow through automatically and create downstream problems. Novel document types - new jurisdictions, new formats, new form versions - cause temporary accuracy drops until the model adapts.
Decisioning layer failures: The most common is dependency on engineering for every policy change. When routing logic is hardcoded, every change requires a developer ticket. This creates a backlog, slows response to regulatory and credit-policy changes, and concentrates institutional knowledge in a team that doesn't understand the policy as well as the credit and risk teams who live with it daily. The second failure mode is inadequate audit trail: lenders discover late that their platform doesn't log decisions at the granularity regulators expect.
How Floowed Addresses Both Layers
Floowed is designed around the specific failure modes that lending operations teams encounter. On document intelligence: the platform was built specifically for the documents that break generalist IDP systems - bank statements with mixed handwriting and printed figures, passbooks with faded or degraded entries, KYC packages containing photocopied or photographed documents. It doesn't just read them; it analyses them into the cash-flow and affordability signals a credit decision runs on. Accuracy of 96-99% on these documents - not on clean test sets - is the design target.
On the decisioning layer: the Decisioning Engine is a no-code, visual policy builder that credit and risk teams use directly (the credit officer remains the day-to-day operator). Routing rules, confidence thresholds, human review queue assignments, approval hierarchies, the credit policy itself - these are configured in the interface without writing code. When the policy changes - a new regulatory threshold, a new approval structure, a new document type variant - the workflow changes in the platform without a development cycle. And it's score-agnostic: bring your own scorecard or a bureau score and the engine absorbs it unchanged - Floowed orchestrates the decision, it doesn't compete with your model. The credit and risk teams who own the policy own and modify the workflow themselves.
The audit trail is field-level: every extraction, every routing decision, every human review action, every approval is logged with timestamp, reviewer identity, and field-level detail. For SOC 2, AML compliance, KYC regulatory requirements, this is the evidence layer that audits require.
This is already running in production. At Alon Capital, founder Rene de Jesus puts it plainly: "Floowed reads the documents, runs our credit policy, and surfaces a decision in minutes."
Pricing is consumption-based on credits, sized to your operation on one short call rather than a long sales cycle, and lands well under the large enterprise platforms - with no per-page costs that compound with volume.
The Common Mistake: Buying Intelligence Without Decisioning
The most common mistake in loan automation procurement is buying a document intelligence platform - an extraction API or OCR-plus-ML service - without a configurable decisioning layer, then trying to build that layer in-house. This works initially. It fails at scale.
The engineering team builds routing logic and exception handling that works for the document types and credit rules that exist at implementation. Six months later, a regulatory change requires a new routing rule. A new segment brings a document type that wasn't anticipated. The approval hierarchy changes after a reorg. Each change requires an engineering ticket, a sprint, a deployment. The backlog grows. The operations team works around the gaps manually. The efficiency gains from automation erode.
The fix is not more engineering - it's a platform where the decisioning layer is as configurable as the intelligence layer. Where the compliance lead can modify a routing rule without raising a ticket. Where the credit team can add a new approval step in the interface. Where the system adapts to the business rather than requiring the business to adapt to the system.
Evaluating Platforms on Both Dimensions
When evaluating loan automation platforms, test both layers explicitly:
On document intelligence: Test on your actual production documents, not demo content. Include your difficult cases - the degraded scans, the handwritten entries, the photographed and skewed uploads, the unusual formats that break your current process. Measure field-level accuracy, and check whether the platform analyses (cash flow, affordability, tampering) or merely transcribes. Evaluate confidence score calibration by checking how often high-confidence extractions are actually correct. A thorough IDP evaluation includes accuracy testing across document quality ranges, not just clean samples.
On the decisioning layer: Have someone from credit, risk, or compliance - not engineering - attempt to configure a routing rule during the demo. Ask how they would modify the human review queue assignment if a new team came on board. Ask what happens when a regulatory threshold changes. If the answer involves a developer ticket or a professional services engagement, that's a signal about where the dependency sits.
On the combination: Evaluate whether the platform treats both layers as first-class capabilities. Extraction-only platforms are missing half the problem. Decisioning-only platforms without strong document intelligence create different bottlenecks. The most efficient loan automation deployments integrate both layers in a single platform where each feeds the other: intelligence determines routing, routing drives review, review improves intelligence.
The ROI case for loan automation is strongest when both layers are working together. Extraction without intelligent routing creates downstream work. Routing without accurate extraction creates review queues full of wrong data. Getting both right is what makes automation self-sustaining rather than requiring constant manual intervention.
Floowed builds preset document workflows for lending and credit teams - reading and analysing real-world loan documents, then running your policy on every application - live in days on your actual documents.