Evaluating the Utility of LLMs for Transaction
Description Classification in Japanese Bank Data

Summary

Bank transaction data is a direct record of the movement of money, and thus one of the most useful sources for understanding the actual economic activity of a business. Efforts to apply such data to real-time credit decisioning for businesses have a long history. Among this data, quantitative fields — balances and deposit/withdrawal amounts — have a stable format and are relatively easy to handle, and are already in practical use as features in credit risk models. By contrast, the qualitative data recorded in the transaction detail (what the transaction was, and who the counterparty was) is highly informative, yet its notation is effectively unbounded and bookkeeping conventions differ from bank to bank — the “many dialects of bank language” problem. Rule-based approaches cannot achieve sufficient coverage against it, and its use has therefore remained limited. This work takes the utilization of that qualitative data as its subject.

This paper reports the development and results of a domain-specialized LLM that automatically converts the description field of Japanese corporate bank transaction data into structured information. Referencing the approach of Slope TransFormer (an OPT-125M model), a precedent in the U.S. B2B credit domain, we applied LoRA fine-tuning in an attempt to adapt the model deeply to Japanese corporate transaction data.

The model is formulated as a task that jointly extracts three fields from the description text: “Category”, “Transaction Description”, and “Counterparty/Intermediary”. In our evaluation, it achieved 99% exact-match accuracy on data covering 41,180 companies (242,638 transactions). It also achieved an inference throughput of 30,000 TPS, demonstrating high processing capacity and cost efficiency in production operation. Within the scope of the test data used, we confirmed that the transaction content and counterparty can be structured with accuracy broadly comparable to human judgment. This means that a path exists for bridging qualitative data — previously unusable — into features that a credit model can consume.

This work further proposes the hypothesis that, in AI implementation for the financial domain, what matters is not dependence on a single general-purpose LLM (a frontier model) but orchestration — selecting and combining the model best suited to each task and domain. The construction of this model is positioned as one element of that orchestration strategy: it demonstrates concretely that there exist domains in which a small model optimized for a specific task — not a general-purpose one — is the superior choice.

As a next step, we intend to build cash-flow features from the transaction data labeled by the LLM, incorporate them into a bankruptcy prediction model, and evaluate how much improvement in predictive accuracy (AR uplift) can be achieved relative to the existing baseline.

1. Introduction

The exponential improvement in the accuracy of large language models (LLMs) is transforming every industry, and finance is no exception. The question is no longer “can an LLM be used?” but “to which problem in our own domain can an LLM be applied so that it actually creates value?” As Emerada has applied this technology to its own domain, one of the most promising use cases we have identified is the problem addressed in this paper: classifying the description field of corporate bank transactions.

Japanese banks generate an enormous volume of transaction records every day, and each record carries a short free-text description that indicates the nature, counterparty, and purpose of the transaction. For Emerada’s cash-flow analytics platform for small and medium-sized enterprises, automatically converting this description field into structured information is a foundational capability for real-time cash-flow visibility, anomaly detection, and credit decisioning.

The problem is harder than it looks. The description fields of Japanese corporate transactions mix standardized codes, free-text company names, abbreviations, and bank-specific notation conventions. Even for the same economic event (e.g. a payroll transfer), many different expressions arise depending on the bank, the branch, and the remitter: 「給与」, 「給与振込」, the half-width katakana 「ｷﾕｳﾖ」, or 「ｶ)○○ｼﾖｳｼﾞ」 with the remitter’s name inlined. This is the many-dialect problem of “bank language”, with a high-dimensional, long-tailed distribution. It is difficult to obtain adequate coverage with a rule-based system alone.

This work is inspired by Slope TransFormer (Wu, 2023). That study LoRA-fine-tuned OPT-125M on just 66K high-quality labels and, on classification of U.S. B2B transactions, achieved 72% exact-match accuracy — exceeding Plaid’s 62% — at a throughput of 500 transactions per second, a 250× speed-up over the previous generation of GPT-based methods.

The central question of this work is: does the same approach work on Japanese corporate bank data?

2. Problem Setting

2.1 Task definition

The task addressed in this work is the automatic extraction of the following three structured fields from the description text of Japanese corporate bank transaction data.

Category is a label that classifies the transaction into a semantic category for financial analysis (e.g. operating income, loan repayment, intercompany transfer). Unlike Counterparty and Transaction Description, Category is not written in the description field; it is inferred from the context of the transaction.

Transaction Description is text indicating the economic content or nature of the transaction (e.g. loan repayment, payroll transfer, social insurance premium). It is derived from information stated explicitly in the description field, though it may require interpreting bank-specific abbreviations or codes.

Counterparty/Intermediary refers to the counterparty company or individual of the transaction (e.g. ｴｰｼﾖｳｼﾞ), or the payment method or intermediary service used (e.g. PayPay, an FB service). Because the description field may contain only the counterparty, only the intermediary, or both, we treat these as a single unified field.

A concrete example of the model’s input and output is shown below.

In this example, from the description field 「振込入金 ｴｰｼﾖｳｼﾞ」 the counterparty 「ｴｰｼﾖｳｼﾞ」 and the transaction content 「振込入金」 are each extracted. By contrast, the Category is not written anywhere in the description field: it is a label inferred from the transaction form (an incoming transfer) and the context of the counterparty. This is what positions the task as a problem requiring semantic inference rather than simple keyword extraction.

Formally, the task is framed as a sequence-to-sequence problem that takes the description text as input and outputs the text of the three fields.

2.2 Why an LLM

The conventional approach to classifying description fields is a rule-based method. For example, one defines in advance a rule that assigns the “borrowing” category when the description field matches 「カリイレキン」 exactly, and classifies by pattern matching. This approach is highly interpretable and works effectively in small, fixed environments.

However, when a rule-based method is applied to Japanese corporate bank transaction data, a limitation of a different nature exists for each of the three fields — Category, Transaction Description, and Counterparty/Intermediary.

• The limit for Category
  In many cases the category cannot be derived directly from keywords; it is necessary to infer the context and direction of the transaction and the counterparty’s line of business. A rule-based method finds such implicit semantic inference difficult.
• The limit for Transaction Description
  The keywords that indicate transaction content differ greatly in notation depending on the bank and the remitter. Interpreting abbreviations and bank-specific codes (e.g. “FB”, “PE”) requires advanced domain knowledge, and there is a limit to creating general-purpose rules.
• The limit for Counterparty/Intermediary
  The names of counterparty companies and individuals are unbounded in number and vary widely in notation, so exhaustive pattern matching is difficult. Moreover, where a counterparty and an intermediary are mixed in the same description field, separating them by simple matching is difficult.

On top of this, because the notation format differs from institution to institution, a rule set must be created and maintained separately for each bank. This maintenance cost grows faster than linearly with the number of financial institutions.

Below is an example in which several banks record different description fields for the same payroll payment.

In addition, even within the same financial institution, the column names and recording formats that contain the description information can differ between ordinary deposit and current deposit accounts. Applying a conventional rule-based method therefore requires formulating and extending separate rules per account type, creating operational complexity and increased development cost. Examples of the differing data formats within the same institution are shown below.

Example of ordinary deposit data format:

Example of current deposit data format:

Against these challenges, we believe an LLM can classify and extract after understanding the description text semantically, at the level of context. It requires no explicit enumeration of rules and can implicitly acquire, from training data, the ability to interpret notational variation, abbreviations, and bank-specific codes. Even for the open-vocabulary problem of counterparty names, the LLM can infer from context a company name it has never seen during training, giving it a structural advantage over pattern matching. One aim of this work is to demonstrate this hypothesis in the concrete domain of Japanese corporate bank data.

In the example in the table below, for a transaction whose description information is 「DF.ｼｰｼﾖｳｼﾞ」, the conventional rule-based method returns “none (unclassifiable)”. This is thought to be because no past transaction history with that company existed and the case was not covered by the existing rule set.

The LLM, by contrast, does not depend on the presence or absence of past transaction history: it correctly infers from the description information that the company is a trading counterparty and classifies the transaction as “operating cash flow”.

3. Related Work

3.1 SlopeGPT: classifying transactions with GPT-4

A pioneering case of applying LLMs to bank transaction data is SlopeGPT (Wu, 2023), announced in April 2023 by Slope, a U.S. B2B payments company.

Fintech companies have traditionally classified transaction data using dictionaries, keywords, and other rule-based approaches. This method had two problems. First, the diversity and idiosyncrasy of transaction descriptions make it difficult or impossible to characterize transactions reliably with rules. Second, the same transaction description can mean entirely different things for different businesses. For example, an ACH (the U.S. electronic payments network) credit may be revenue for one business and a source of financing for another.

SlopeGPT addressed these challenges by using GPT embeddings to ingest transaction data and decompose cash flow into components such as revenue, expenses, loans, and investments. SlopeGPT used GPT-4 to classify bank data more accurately, providing a high-resolution picture of the business and improving risk-detection accuracy.

However, SlopeGPT had practical constraints. Calling the GPT-4 API sequentially for each transaction scaled poorly in both speed and cost, and was unsuited to large-scale production operation. The same issue was observed in this work: calling an API per transaction proved inefficient in both time and cost.

3.2 Slope TransFormer: the shift to a small, domain-specialized model

To overcome the limitations of SlopeGPT, Slope announced Slope TransFormer (Wu, 2023). This method is the direct inspiration for our work, and applying its architecture and training strategy to Japanese corporate transaction data is our starting point.

TransFormer adopts OPT-125M, an efficient open-source foundation model. Why such a “small” model? Considering the dimensionality of the language of transactions: it is far too vast to solve with rules, yet extremely small compared with the English language as a whole. The task is also singular, and simple by LLM standards.

For training, Slope TransFormer adopted LoRA (Low-Rank Adaptation of Large Language Models). LoRA enables efficient fine-tuning of a foundation model by learning a simplified representation while keeping the original model weights frozen. It also mitigates catastrophic forgetting, in which important previously learned knowledge is lost when model weights change substantially.

Slope TransFormer labels more than 500 transactions per second, a 250× speed-up over SlopeGPT. Taking human labeling accuracy as 100% exact match, Slope TransFormer’s accuracy is reported to be over 72%, exceeding Plaid‘s 62%. (Plaid is a fintech service widely used by North American financial apps for connecting bank transaction data and the like; it also provides its own transaction labeling.)

This work is an attempt to apply that approach to a new domain — Japanese corporate bank transaction data. The main differences from Slope TransFormer are the notational diversity specific to Japanese (a mix of half-width katakana, full-width characters, and bank-specific codes) and the additional inference of “Category”, which is not written in the description field.

3.3 Rogo Big Finance Benchmark: the importance of model orchestration

A useful finding on the limits of depending on a single model in financial AI is the Big Finance Benchmark (BFB), published by Rogo AI in May 2026.

BFB is an evaluation set of 928 questions covering work actually performed in banking, private equity, research, and asset management. Its principal conclusion is that “there is no single best model.” The leading models — Opus 4.7, GPT-5.5, and Sonnet 4.6 — differ by less than 0.3 points in overall score, yet each is strong on different workflows, and no model leads across all areas.

Furthermore, even coarse routing by workflow and source type yields an accuracy improvement of roughly 4.5 points over the best single model, and optimal oracle routing yields an improvement of 13.2 points. This finding suggests that the essence of financial AI implementation is not “which single model is best” but “which model to assign to which task”, and the construction of a small, task-specialized model in this work is positioned as one element of that orchestration strategy.

4. Data

Data source

This work uses ordinary deposit and current deposit data from a Japanese bank. The full dataset contains 242,638 transaction records across 41,180 companies. We randomly split the data 80% (194,110 records) and 20% (48,528 records) into training and test sets respectively. No filtering by industry, company age, or size was applied; the data covers all of the bank’s corporate customers.

Preprocessing the description field

Description-field information does not always fit in a single field; it may be scattered across several. For example, in current-deposit credit transactions, the counterparty information is often recorded in the “description” field and the transaction content in the “payment amount” field. In such cases we merge the information from the “description” and “payment amount” fields into a single text and use it as the description. Conversely, for debit transactions the transaction content is recorded in the “deposit amount” field, so we merge the “description” and “deposit amount” fields and use that as the description.

Creating ground-truth labels

Using the merged “description”, we created ground-truth data for each transaction record in the following format.

The “=>” functions as a special token that lets the model recognize the boundary between input and output. The model is trained to take “description =>” as input and then output the three fields, comma-separated.

For creating ground-truth labels we adopted a hybrid approach combining rule-based generation with manual human annotation, as follows.

• Category: based on Emerada’s own transaction classification rules, with the results of applying those rules reviewed and corrected by humans to produce the final labels.
• Counterparty/Intermediary and Transaction Description: we first examined a large sample of description fields by hand, had humans identify and analyze recurring patterns, and designed rules on that basis. For cases the rules could not cover, or ambiguous cases, humans judged and labeled them manually.
• Different rule sets were used for ordinary and current deposits. Because the difference in description-field format between the two account types is large, separate manual analysis was required per account type in rule design as well.

Thus the ground-truth data does not rely on automatic rule application alone: it is positioned as work in which judgment and verification by humans with domain knowledge are indispensable. Given that the quality of the ground-truth data directly determines the accuracy of the model, we consider this manual annotation process to be important.

A concrete example of the ground-truth data is shown below.

Label distribution

Not every transaction in the data has labels for all three fields. For example, there are many cases in which only the transaction is recorded in the description field and there is no corresponding information within it. Where a label cannot be assigned we set it to “none”; transactions in which all three fields are “none” were excluded from the training and test data.

Across the whole dataset, the distribution of “none” for each field is as follows.

5. Model Architecture and Training

5.1 Model selection: OPT-125M

As with Slope TransFormer (Wu, 2023), we adopted OPT-125M (Open Pre-trained Transformer, 125M parameters), the open-source foundation model released by Meta AI, as our base model.

Our reasons for choosing a relatively small model of 125M parameters, rather than a large general-purpose LLM (e.g. GPT-4, Gemma 2 9B), are as follows.

First, from the standpoint of task dimensionality. The dimensionality of the language of transactions is far too vast to solve with rules, yet extremely small compared with the English language as a whole. The task is also singular and, by LLM standards, fairly simple. Building general AGI may require 77 billion parameters, but that is overspecified for transaction classification. The vocabulary space of description fields is certainly vast, but it remains a bounded domain — bank transactions — and a large model with general language understanding is excessive for this task.

Second, from the standpoint of inference speed and scalability. Large models are expensive to call by API and slow to respond, making them unsuited to this work’s use case of batch-processing transaction data on the order of hundreds of thousands of records. A small model such as OPT-125M can be self-hosted and, with sufficient infrastructure, has been reported to label more than 500 transactions per second (Slope TransFormer (Wu, 2023)).

Third, from the standpoint of cost efficiency. Applying a closed, large API model to every transaction causes cost to grow faster than linearly with each API call. A small specialized model incurs the cost of provisioning an inference environment once, with no per-call API charges.

5.2 Training: LoRA fine-tuning

For training we adopted a fine-tuning method called LoRA (Low-Rank Adaptation of Large Language Models) (Hu et al., 2021).

Specifically, instead of directly updating the large matrices (weights) in each layer of the model, LoRA approximates only the change with the product of two very small matrices. If the original weight is a 1000×1000 matrix, it is represented by the combination of two thin matrices, 1000×16 and 16×1000. This “16” is the value called the rank; in this work we used r=16.

This device reduces the number of parameters that need to be trained to about 0.5% of the whole model. OPT-125M has roughly 125 million parameters, but LoRA actually updates only about 600,000. As a result, training completes with far less GPU memory and time than full fine-tuning of all parameters.

Our reasons for adopting LoRA are as follows.

First, computational efficiency. Compared with full fine-tuning, which updates all parameters, LoRA substantially reduces the GPU memory and compute time required for training. This work assumes training on Azure ML, so the cost advantage is important.

Second, avoiding catastrophic forgetting. Because LoRA learns a simplified representation while keeping the original model weights frozen, it mitigates “catastrophic forgetting”, in which important previously learned knowledge is lost when model weights change substantially. Retaining the general world knowledge that OPT-125M acquired during pre-training (e.g. recognizing company and place names) while acquiring bank-transaction domain knowledge is important for this task as well.

5.3 Open-source vs. closed models

Behind our adoption of an open-source model such as OPT-125M lies a practical judgment in comparison with closed models (GPT-4, Claude, etc.).

Concerns about closed models include the following.

• Data privacy: bank transaction data is highly confidential, and sending it to an external API carries data-governance risk. With an open-source model, inference can be completed entirely within our own environment, with no need to transmit transaction data externally.
• Cost: processing transactions on the order of hundreds of thousands of records sequentially by API drives operating cost to an unrealistic level.
• Latency and predictability: ChatGPT may return ten different answers to the same prompt asked ten times, whereas a model fine-tuned for a specific task behaves deterministically in practice. From the standpoint of reliability in a production system, this consistency is an important property.

Before this work, Emerada attempted transaction-classification inference using the Azure OpenAI API. The average processing time per transaction was 12 seconds, which works out to several days to process the transaction data of just 350 companies (tens of thousands of transactions). It became clear that calling an API sequentially per transaction is inefficient in both time and cost.

Advantages of open-source models include the following.

• Complete data control through self-hosting, and low-latency inference.
• Customizability: domain-specialized fine-tuning via LoRA is possible, making it easy to adapt to the peculiar language space of bank transactions.
• Cost efficiency: once trained, large-volume inference is possible with no additional API charges.

6. Inference Pipeline and Evaluation

6.1 Inference pipeline

Preparing the input

Inputs are prepared with the same procedure as the data preprocessing described in Section 4. Specifically, after merging description information scattered across several fields, the inference text is composed in the following format.

Everything after “=>” is left blank when fed to the model, and the model generates the subsequent text (Counterparty/Intermediary, Transaction Description, and Category, comma-separated). Concrete input examples are shown below.

Deployment: Azure ML batch endpoint

The trained model was deployed as a batch endpoint on Azure Machine Learning (Azure ML). A batch endpoint is an inference platform for processing large volumes of data together and asynchronously; unlike an online endpoint intended for real-time immediate response, it is optimized for efficiently processing tens of thousands to hundreds of thousands of records in bulk.

This work’s use case assumes an operating model in which transaction data accumulated monthly or weekly is batch-processed together, and a batch endpoint fits that requirement. At inference time, the trained LoRA adapter is merged into the base model (OPT-125M) and executed with 4-bit quantization applied to improve memory efficiency. One NVIDIA H100 (40 cores, 320GB RAM) is used as the inference GPU. The NVIDIA H100 delivers acceleration over CPU servers for LLM training and inference, and has ample specification for the large-scale batch inference required in this work.

6.2 Evaluation methodology

① Accuracy metrics

To evaluate the accuracy of the model’s inference results, we use the following two quantitative metrics for each inferred field (Category, Transaction Description, and Counterparty/Intermediary).

Exact Match Accuracy: the proportion of cases in which the model’s predicted output matches the ground-truth label exactly. Its range is 0 to 1 (or 0%–100%), and it is a strict criterion: a difference of even a single character is judged a mismatch. We position it as the primary evaluation metric of this work; it is also adopted in Slope TransFormer (Wu, 2023), which makes benchmark evaluation possible in a comparable form.

Jaccard Similarity Index: treats the predicted text and the ground-truth label as sets of words (tokens) and measures the proportion of overlap. Its range is 0 to 1, where 0 means complete mismatch and 1 complete match. As a complement to Exact Match, its distinguishing feature is that it can also quantify partial correctness.

As a concrete example, if the ground-truth label is 「ｲｰ ガス コウギヨウ」 and the prediction is 「ｲｰ ガス」, the exact-match accuracy is 0, but the Jaccard similarity is:

— capturing partial agreement quantitatively. The Jaccard Similarity Index is thus well suited to evaluating cases in which the model, while not achieving an exact match, is broadly on the right track; combined with Exact Match Accuracy it enables a more multi-faceted accuracy evaluation. This metric is also used in Slope TransFormer (Wu, 2023).

② Speed metrics

Tokens per Second (TPS): in addition to accuracy, we measure the model’s processing speed in tokens per second. TPS indicates the number of tokens (the smallest unit of information — short strings — by which a model processes text) the model can generate per second.

TPS bears directly on estimating processing capacity in production operation. For example, it provides the basis for back-calculating the GPU resources and cost required to process tens of thousands of transaction records monthly, and it is an indispensable complementary metric for evaluating practicality as a system — something accuracy metrics alone cannot capture.

Transactions inferred per second: as a more intuitive speed metric complementing TPS, we compute the number of transactions the model can process in one second. This metric is the average obtained by dividing the total inference time for the entire test set by the number of transactions.

③ Other metrics

Inference coverage: defined as the proportion of transactions whose ground-truth label is not “none” for which the model returned a valid inference result — i.e. did not output “none” or a blank.

7. Results

7.1 Test results

The results of running the trained model on the test transaction data (48,528 records) and evaluating its output are shown below.

Exact-match accuracy, Jaccard similarity, and inference coverage

Exact-match accuracy exceeds 99% for each inferred field and for all fields combined — very high. Jaccard similarity is correspondingly close to 100%. Inference coverage is 100% for Category, but 99.8% and 99.9% for Transaction Description and Counterparty/Intermediary respectively, indicating a small number of transactions for which inference was not produced. We believe this stems from the fact that, in the training data, “none” ground-truth labels were numerous for Transaction Description and Counterparty/Intermediary (69% and 23% respectively). In other words, the model has learned that these two fields are often “none”, and consequently infers “none” for a handful of transactions where it is not.

Inference speed

The model’s inference speed of 30,000 TPS (tokens per second) shows extremely high processing performance. In our evaluation it processed 48,528 test records in about 54 seconds, achieving 899 transaction inferences per second.

Applied to practice, this processing capacity means a financial institution’s annual transaction data (roughly 2 million records) can be processed in about 37 minutes. On infrastructure cost, an estimate based on Azure Machine Learning (instance: Standard_NC40ads_H100_v5, USD 10.12 per hour per node) puts the cost of processing 2 million records at approximately ¥1,200 — demonstrating strong cost-performance in production operation.

7.2 Comparison with the target benchmark

The target benchmark for this work is based on the results of Slope TransFormer (Wu, 2023). Note that Slope TransFormer infers only Counterparty/Intermediary, whereas this work infers three fields simultaneously. We therefore make the benchmark comparison below only against the inferred field Counterparty/Intermediary.

Benchmark comparison of accuracy and coverage

Our model recorded 99.5% exact-match accuracy, greatly exceeding Slope TransFormer (72.5%) and demonstrating overwhelming discriminative performance. On Jaccard similarity — which evaluates output text composition and token similarity — the proposed model also reached an extremely high 99.7%, demonstrating superiority over the existing Slope TransFormer (87.0%). Furthermore, the model achieves an inference coverage of 99.9%, far higher than our existing rule-based method. Combining high coverage with the very high accuracy described above, we believe its comprehensiveness in production operation is strong.

Benchmark comparison of inference speed

The model developed in this work recorded a high generation throughput of roughly 30,000 TPS counting only new output (excluding the prompt), a roughly 60× speed-up over Slope TransFormer (500 TPS). It also reached about 900 transaction inferences per second, overwhelming Slope TransFormer (500+) and GPT-5-mini via an external API (~0.08). This remarkable speed is underpinned by a hardware mechanism: applying large-scale parallel decoding at batch size 256 to the lightweight OPT-125M model makes maximal use of the enormous memory bandwidth of the NVIDIA H100. Because the inference environments of the models differ, this is not a strict one-to-one comparison of architectures in isolation; nevertheless it is a meaningful benchmark showing that this model has overwhelming real-time performance and practicality for high-volume transaction processing in practice.

7.3 On the accuracy gap

The results of this work are extremely high on every metric, and in particular the exact-match accuracy exceeding Slope TransFormer’s 72.5% by about 27 points is worth noting. The following factors may account for this large difference.

The nature of the ground-truth data

As described in Section 4, the ground-truth labels in this work were created with a hybrid approach combining rule-based generation and manual annotation. In other words, the model is learning labels derived from human-designed rules.

Because the test data is also evaluated against labels generated by the same rules, it is possible that the patterns the model learned and the patterns used in test evaluation coincide to a high degree. Put differently, the current evaluation may be measuring “how well the rules can be reproduced” and may not reflect true generalization performance.

Differences in task definition from Slope TransFormer

Slope TransFormer adopts annotation by human experts as its ground truth, achieving 72.5% on data containing greater diversity and ambiguity. The ground-truth labels in this work, by contrast, are rule-based and highly consistent, so the difficulty of the task may differ.

Future evaluation work

To validate the model, we believe the following additional evaluations are needed.

• Confirming the model’s behavior on new counterparties and new patterns for which no rules are defined.
• Application experiments on data from a different financial institution.
• Re-evaluation on an independent test set produced by human annotation.

8. Toward Production Use

Bank transaction data is the movement of money itself, and there is no doubt that it is extremely useful data for directly understanding the reality of a business’s economic activity. Efforts to use this data for real-time credit decisions on businesses have been under way for some time.

Quantitative data such as balances and deposit/withdrawal amounts has a stable format and is relatively easy to handle, and its use as features in credit-risk models is already advancing in practice. Qualitative data recorded in the transaction details — the content of the transaction, the counterparty — carries a great deal of information, yet its notation is effectively unbounded and each bank has its own recording conventions. Because of this many-dialect problem of bank language, rule-based methods could not secure sufficient coverage, and its use has been limited.

In this work, we applied a domain-specialized LLM to labeling that qualitative data and confirmed that, within the scope of a certain body of test data, it can structure transaction content and counterparties at roughly the same accuracy as human judgment. This means that a path exists to bridge previously unusable qualitative data into features that a credit model can consume. As a next step, we intend to construct cash-flow features from LLM-labeled transaction data, incorporate them into a bankruptcy-prediction model, and verify how much improvement in predictive accuracy (AR) can be achieved relative to the current baseline.