Finance runs on documents before it runs on models
Most finance AI conversations open with prediction: probability of default, fraud scores, trading signals. Those are the hardest systems to put into production and the most tightly constrained once they are there. The work that pays for itself in the first year is almost always document work. A bank, a leasing company, a portfolio management firm or a payments institution runs on scanned paper: identity documents, trade registry gazette entries, signature circulars, facility agreements, prospectuses, custody statements, correspondence with a supervisor. The people who read that paper are expensive and scarce. Language models are genuinely good at reading, extracting and summarising when they are forced to cite the source. That is a narrower claim than most vendor decks make, and it is the one that survives a compliance review.
The distinction that decides everything downstream is between a system that produces a decision and a system that produces a draft with evidence. A model that outputs decline this application has performed a legally consequential act, and someone will eventually have to reconstruct it, justify it and defend it. A model that outputs here are the four clauses that govern the answer, here is the page and the paragraph each one came from, here is a proposed summary, has produced a work product that a named human accepts or rejects. The technology underneath can be identical. The regulatory weight, the evidentiary burden and the cost of being wrong are not remotely the same, and most failed finance AI projects we have seen failed by blurring the two.
This article follows the order in which we scope these programmes: what genuinely works now, what is hard or heavily constrained and why, what the regulatory layer actually requires, and what the architecture has to look like if it is going to survive an examination rather than merely survive a demo. Every use case in the first half is document-heavy and every one of them keeps a human in the loop, which is a design choice we defend rather than a limitation we apologise for. If you are still deciding whether AI belongs in your institution at all, the general framing in our overview of AI for businesses is a better starting point; this article assumes you are past that stage.
KYC and onboarding: extraction with a human on the exception queue
Customer onboarding is the cleanest first case in almost every institution we work with. The input is a bundle: identity document, address evidence, trade registry gazette page, signature circular, tax certificate, sometimes a power of attorney, arriving as scans, phone photographs and the occasional fax-quality PDF. The output is a structured record: legal name, tax number, incorporation date, registered address, authorised signatories with their limits and expiry dates, shareholders above whatever threshold your policy sets, plus a confidence score per field and a pointer to the exact page and region each value was read from. That last part is not decoration. Without a pointer back to the pixel, the reviewer has to reopen the whole bundle and the time saving evaporates.
The accuracy you should plan for depends far more on input quality than on model choice. On clean, machine-generated PDFs we typically see field-level accuracy in the 95 to 98 percent range on well-defined fields such as tax number and incorporation date, and appreciably lower, often 85 to 92 percent, on free-text fields such as signature authority limits where the wording varies between notaries. On phone photographs taken at an angle across a branch counter, expect 8 to 15 points lower across the board until you add a capture-quality gate that rejects the image and asks for a retake. Straight-through processing, meaning a file no human touches, realistically lands between 55 and 75 percent of volume once confidence thresholds are tuned.
The human sits on the exception queue, not on every file, and that queue deserves as much design attention as the model. Route on confidence, on business risk and on disagreement between extractors, then show the reviewer only the fields that failed, with the source region highlighted, rather than the whole document. A reviewer shown three fields and a cropped image resolves a file in 40 to 90 seconds; a reviewer handed the raw bundle takes 8 to 15 minutes, which is exactly what they were doing before. The economics of the entire project live in that difference. We also insist on a sampling loop: 2 to 5 percent of auto-approved files are reviewed anyway, blind, so the straight-through path has measured accuracy rather than assumed accuracy.
The unglamorous truth is that most of the elapsed time in these projects goes on inputs, not on inference. A typical onboarding pilot over a corpus of 20,000 to 80,000 historical files takes 8 to 12 weeks, and roughly half of that is document inventory, deduplication, deciding which of the four competing internal definitions of authorised signatory the institution actually uses, and building an annotated set of 300 to 800 documents the system is scored against. If that sounds like data engineering rather than AI, it is, and the data-readiness work we describe elsewhere is the single strongest predictor of whether a pilot reaches production or quietly stops after the demo.
Contracts, prospectuses and credit files: review that cites its source
Contract and prospectus review is the second reliable case. The input is a long document, typically 15 to 300 pages: a facility agreement, a framework services contract, a fund prospectus, a master agreement with its schedules, a portfolio transfer term sheet. The output is not a summary in prose. It is an answer against a defined clause taxonomy: does this agreement contain a change-of-control clause, what is the governing law, what are the events of default, is there a most-favoured-nation term, what is the notice period, and for each of those, the clause number, the page and the exact sentence the answer rests on. Fluent prose without a clause pointer is worse than useless, because it invites the reviewer to trust it.
The metric that matters here is recall, not precision, and teams get this backwards constantly. Missing a clause that exists is a diligence failure; flagging a clause that turns out to be irrelevant costs a reviewer thirty seconds. We therefore tune retrieval and extraction to favour over-flagging, and we report recall per clause type rather than as a single average, because an average always hides the two or three clause types that are genuinely hard. On a taxonomy of 40 to 120 clause types, we typically see recall in the 90 to 96 percent range on common, well-templated clauses and 70 to 85 percent on rare or oddly drafted ones, which is precisely why the reviewer stays in the process.
Credit-file summarisation has the same shape. A file of 30 to 120 pages containing financial statements, the analyst's prior memo, collateral valuations, sector notes and internal correspondence goes in; a two-page draft memo in which every assertion carries a page reference comes out. The realistic gain is that an analyst who used to spend 60 to 120 minutes building a first draft spends 20 to 35 minutes correcting one, and the corrections cluster in predictable places. The dangerous failure is not a fabricated number, which reviewers catch immediately; it is a silent omission, a contingent liability sitting in a footnote that never reached the draft. Reviewers in legal teams will recognise the pattern from document review in legal work, where the same asymmetry applies.
Because omission is the real risk, evaluation cannot be a satisfaction score. We build a graded set of 150 to 400 real files with a human-authored list of the facts that must appear in any acceptable summary, and we score coverage of that list rather than similarity to a reference text. A summary that reads beautifully and misses two of the twelve required facts fails, and it should fail loudly. This is more expensive to build than a generic benchmark, and it is the only version of the exercise a credit committee will accept, because it maps directly onto the question they actually care about: what would we have missed if we had trusted this draft?
Policy answers, reconciliation breaks and service assist
Internal policy question answering over regulation, internal circulars and product manuals is the case with the widest user base and the lowest risk per answer. The input is a natural-language question from a branch employee, an operations analyst or a compliance officer. The output is a short answer, the clause it comes from, the document version and its date, and an explicit statement when the corpus does not contain an answer. That last behaviour has to be engineered; models do not volunteer ignorance. In our builds an answer is only rendered when a retrieved passage clears a similarity and reranking threshold, and otherwise the system returns no supported answer found plus the three closest documents, which users accept far more readily than a confident wrong answer.
Retrieval quality decides this use case entirely. Pure vector search over a Turkish regulatory corpus underperforms on exactly the queries that matter, because circular references, article numbers and defined terms are lexical rather than semantic, and an embedding will cheerfully treat two different article numbers as near neighbours. We use hybrid search, combining a lexical index with embeddings, then rerank the top 50 candidates, which adds roughly 100 to 400 milliseconds and typically moves the answer-with-correct-citation rate from the 65 to 75 percent band into the 85 to 92 percent band. Turkish morphology and stemming add their own difficulties, described in the context of Turkish legal corpora, and those problems reappear verbatim in banking circulars and product documentation.
Reconciliation exception handling and customer-service assist complete the working set. In reconciliation the model does not match transactions; a deterministic engine does that, and it should. The model reads the 3 to 8 percent of items that break, drafts a classification and a proposed resolution with the supporting evidence attached, and in our experience makes 70 to 85 percent of breaks resolvable without escalation to a second team. In service assist, the agent's draft reply must cite the tariff table row or the contract clause it relies on, and the agent sends nothing they have not read. First-draft acceptance rates of 50 to 70 percent are normal and are a perfectly good outcome; materially higher usually means the agents have stopped reading.
Where it is hard: autonomous credit decisions and trading
Autonomous credit decisioning is where enthusiasm meets the wall, and the reason is not simply that regulators disapprove. A language model asked to approve or decline a loan has no stable, inspectable reason for its answer. You can ask it to explain, and it will produce a fluent rationalisation that may or may not correspond to whatever actually drove the output, which is the worst possible property for a decision you may have to defend three years later. Conventional scorecards are dull by comparison and vastly better on this axis: the weights are visible, the reason codes are enumerable, population stability can be monitored, and an examiner can be handed a document that reconstructs any individual decision. Fluency is not explanation, and in credit the two are routinely confused.
The second problem is proxy discrimination. Remove the protected attribute and a sufficiently expressive model will happily reconstruct it from postcode, employer, device fingerprint, merchant mix in transaction history and even application timing. Detecting that requires deliberate testing against held-out protected attributes, which many institutions do not lawfully hold, so the test becomes a project of its own. The evidentiary burden compounds it: you must be able to show not only how the decision was reached, but that the version of the model which made it was the version you had tested, on the data you had validated, with the thresholds in force on that date. If your pipeline cannot reconstruct that state for an arbitrary past decision, you do not have a deployable credit model whatever its accuracy.
Trading is harder still and for different reasons: markets are non-stationary and adversarial, backtests overfit silently, and the feedback that would tell you the model is wrong arrives together with your losses. We do not build autonomous trading agents and we would advise against buying one. The general pattern deserves stating plainly because it reaches well beyond finance: Gartner's June 2025 press release, based on a poll of over 3,400 respondents, projected that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Scope decides more than model selection here, and where you draw the boundary of the project usually settles the outcome before a single component is chosen.
The regulatory layer: creditworthiness is an Annex III high-risk use
Under the EU AI Act, Regulation (EU) 2024/1689, AI systems used to evaluate the creditworthiness of natural persons or to establish their credit score fall within Annex III, the list of high-risk use cases. That classification carries the heavy obligations: a risk management system, data governance for training and validation data, technical documentation, record-keeping, transparency towards deployers, human oversight designed into the system rather than bolted onto it, accuracy and robustness requirements, a quality management system, conformity assessment and registration. The regulation entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions. Turkish institutions with EU customers, EU subsidiaries or EU-facing output are inside its scope regardless of where the model happens to run.
Here is the part most compliance pages have not caught up with. Annex III standalone high-risk systems were deferred: they no longer apply from 2 August 2026 but from 2 December 2027. The instrument is Regulation (EU) 2026/1744 of 8 July 2026, which amends Regulation (EU) 2024/1689 and was published in the Official Journal on 24 July 2026, entering into force on 27 July 2026. Annex I product-embedded high-risk systems apply from 2 August 2028. If a supplier questionnaire, a board paper or a compliance page you rely on still states that the full high-risk regime binds from 2 August 2026, it is out of date; the European Commission page at digital-strategy.ec.europa.eu is the citation we hand to legal teams, and the corrected timeline in detail covers the rest.
Deferral is not exemption, and several parts of the regulation already bite. The prohibited practices in Article 5 and the AI-literacy obligations have applied since 2 February 2025. Obligations on providers of general-purpose AI models under Articles 51 to 56 have applied since 2 August 2025, which matters to you as a deployer because it shapes the documentation you can demand from a model vendor during procurement. Article 50 transparency was not delayed and took effect on 2 August 2026, with a grace period to 2 December 2026 under Article 50(2) for synthetic-content marking on systems already on the market, and the same 2 December 2026 grace period for the new prohibitions the omnibus introduced.
The practical reading for a finance team is that you have a defined runway rather than a reprieve. Assembling the risk file, the data governance record, the logging design and the human-oversight model takes considerably longer than the compliance calendar suggests, and the institutions that will be comfortable in December 2027 are the ones treating the interval as build time rather than waiting time. One caveat we state openly: HatsonTech is an engineering company, not a law firm, and everything here is how we design systems to be defensible, not legal advice. The classification of your specific system and the obligations that follow are a call for your own counsel and compliance function to make.
KVKK, article 11(g) and the Turkish picture
In Türkiye the binding constraint today is data protection law rather than AI-specific law. Law No. 6698 gives the data subject, in article 11(g), the right to object to a result produced against them by analysing their data exclusively through automated systems. For a lender that single clause contains the whole autonomous decisioning question: an adverse decision produced solely by automated processing is contestable, and the institution has to be able to show a meaningful human element rather than a nominal one. Alongside it, article 5 governs lawful basis and article 6 governs special categories of personal data, which is why health information appearing in a bancassurance or insurance file changes the analysis rather than merely adding volume to it.
Articles 10 and 12 do quiet damage to naive architectures. Article 10 is the duty to inform, which means your privacy notice has to describe the automated processing you actually perform, in language a customer can read, before you perform it. Article 12 is the data security obligation, and it is the one that catches AI logging designs, because the natural engineering instinct is to store every prompt, every retrieved passage and every output forever in a warehouse the whole analytics team can query. KVKK's guide on generative AI and the protection of personal data, listed on the authority's Rehberler index at kvkk.gov.tr, is the reference we point institutions to, and we work through it in a dedicated article.
Türkiye has no dedicated AI law in force. Regulation proceeds by adapting existing instruments: Law No. 6698, the Turkish Penal Code, Law No. 5651 and the Turkish Commercial Code. Bills have been submitted to the TBMM and none has been enacted, so planning around a hypothetical enactment date is not a strategy; we set out the current position in our review of the Turkish regulatory landscape. Separately, the banking and capital-markets regulators impose their own information-systems, outsourcing and data-localisation expectations on the institutions they license, and those frequently constrain an architecture harder than data protection law does. We deliberately quote no specifics here: the applicable requirements have to be confirmed with your own compliance function, which knows which of them your licence attracts.
What an examiner actually asks for
Examiners ask a small number of questions and they ask them about a specific case, not about your architecture in the abstract. The first is: show me how this decision was reached, on this date, for this customer. Answering it requires you to reproduce the state of the system at that moment, which means the model identifier and version, the prompt template and its version, the retrieved passages together with the document versions they came from, the decoding parameters, the guardrail verdicts, the raw output, any post-processing, and the identity of the human who accepted or overrode it. If any element of that is missing, the honest answer is that you cannot reconstruct the decision, and that answer is expensive.
The second question is: how did you know it worked. This is where evaluation evidence stops being an engineering nicety and becomes a document. What we hold is a dated artefact per release: the evaluation set and its version, the date it was run, metrics broken down by category rather than a single headline number, the model version tested, the known failure modes, and a named person's sign-off. When the system changes the artefact is regenerated and the previous one retained, so the series shows how quality moved over time. Institutions that cannot produce this end up arguing from anecdote in front of an examiner, and anecdote loses every time.
The third question is about drift and change: what has changed since, and how would you know if the system had degraded. That needs production monitoring using the same metric definitions as the pre-release evaluation, not a separate dashboard measuring adjacent things. In practice we sample 1 to 3 percent of live traffic for continuous scoring, alert on retrieval-quality drops before answer-quality drops because retrieval degrades first and answers degrade second, and re-run the full evaluation set on every model or prompt change, which for a live system is more often than teams expect. The measurement discipline behind all of this is the one described in the RAG evaluation metrics we use.
The architecture that survives an audit
Four properties do most of the work. First, retrieval with citations that resolve to a source document, a version and a clause, so every assertion in an output can be followed back to a page and a paragraph rather than to a file name. Second, immutable logs of the full interaction: request identifier, timestamp, actor and role, prompt template version, retrieved chunk identifiers with the content hash of the document version they came from, model identifier and parameters, raw output, guardrail results and final disposition. Write them append-only to object storage with an object-lock or equivalent retention policy, hash-chain the daily batches and store the digest separately, so a modified log is detectable rather than merely discouraged.
Third, human sign-off recorded as a first-class event rather than a checkbox on a screen. A review event carries its own identifier, the reviewer, the exact artefact they were shown by reference to an immutable snapshot, what they changed, how long they spent and the outcome they chose. This is the record that answers an article 11(g) question about meaningful human involvement; a boolean column with a timestamp does not answer it, and it will not answer it in front of an auditor either. Fourth, evaluation evidence held as a dated artefact per release. Together these four give you the ability to reconstruct any individual decision without depending on anyone's memory, which is the actual test being applied.
Be concrete about volume, retention and access, because that is where these designs quietly fail. A full interaction record runs 4 to 12 kilobytes, so a million interactions is roughly 4 to 12 gigabytes before indexing: unremarkable to store, expensive to store badly. We pin the retention period to that of the underlying business record rather than inventing an AI-specific one, and we let compliance lengthen or shorten it. Access is narrower than teams assume: the case owner, their supervisor, internal audit and compliance, with every read logged, customer identifiers pseudonymised in the log store and free-text prompts redacted for personal data before they land. Article 12 security obligations apply to the audit trail exactly as they apply to the source system.
How we build this at HatsonTech
Our finance work starts from the document side, because that is where the value and the evidence both sit. In practice a first engagement is a scoped pilot on one corpus with one clear decision behind it: an onboarding queue, a clause taxonomy over a facility agreement population, or a policy corpus of regulation and internal circulars. We build the annotated evaluation set before we build the pipeline, we report per-category numbers rather than a headline accuracy figure, and we say plainly when a use case should not be automated at all. Six to ten weeks is the usual span for a pilot over 50,000 to 200,000 documents, and the deliverable includes the evaluation artefact, not only a working demo.
The retrieval layer absorbs most of the engineering time, and it is the part that decides whether an auditor can follow an answer back to its source. Our RAG and semantic search practice is built around hybrid lexical and vector retrieval, reranking, and citation anchors that resolve to a document version and a clause rather than a file name. We have built the same machinery in adjacent domains: caseon.ai for legal research and DiligenceAI for contract due diligence, both of which face the identical problem of an expert who will not accept an answer without seeing the clause it came from, and both of which taught us that citation quality is a product feature rather than a technical detail.
What we will not do is sell an autonomous decisioning system into a regulated credit process, or promise that a model removes the reviewer. The design we defend is narrower and duller: the machine reads, retrieves, extracts and drafts with citations; a named person decides; the system records what was shown, what was decided and who decided it, in a form that still reconstructs three years later. That is less exciting than the demo, and it is the version still running after the first examination. If you are scoping something in this space, the useful first conversation is about the corpus and the decision behind it, not about which model to use.