SME-Ledger from messy massages logs

SME-Ledger uses a LoRA-specialized, quantized Gemma 3 270M model to turn transaction messages into a local financial ledger and deliver personalized SME financial insights entirely on-device.

Comment

Gemma-SME Ledger

Project Story

About the Project

Gemma-SME Ledger is an on-device financial intelligence system designed to transform unstructured financial transaction messages into structured financial records and useful financial insights.

The project started with a specific problem in Kenya: a large portion of the financial history of individuals and small businesses already exists inside their phones as M-Pesa transaction SMS messages. These messages contain valuable information about income, expenses, merchants, transfers, withdrawals, balances, loans, and payments, but they are difficult to analyze manually.

M-Pesa was therefore the original entry point for the project.

However, as the project progressed through the Africa Deep Tech Challenge 2026 semifinal evaluation, an important limitation became apparent. The initial model had been trained on only around 200 examples, primarily focused on M-Pesa messages. Although this allowed the model to learn the basic extraction task, testing showed that performance could degrade when the model encountered transaction formats, domains, or questions that were different from the narrow training distribution.

This became one of the most important lessons of the project:

A small model does not only need enough data. It needs sufficiently diverse data.

Instead of responding by simply increasing the model size, I redesigned the training strategy.

The model was expanded from a narrow M-Pesa-focused dataset to approximately 20,000 synthetic and instruction-tuning examples covering a much broader financial transaction domain.

The new training data includes:

  • M-Pesa transactions
  • Pochi transactions
  • Paybill transactions
  • Till and merchant payments
  • Money sent and received
  • Banking messages
  • Bank-to-wallet transfers
  • Wallet-to-bank transfers
  • Withdrawals
  • Airtime transactions
  • Fuliza transactions
  • Loan-related transactions
  • Reversals
  • Failed transactions
  • Different transaction-message formats
  • Financial extraction tasks
  • Capability-oriented questions and instructions

The goal is therefore no longer to build a model that only recognizes M-Pesa SMS templates.

The goal is to build a lightweight financial transaction intelligence model capable of understanding diverse transaction messages, while remaining small enough to run locally on constrained hardware.

M-Pesa remains an important use case and the original inspiration, but the underlying problem is much broader: financial transaction information is frequently trapped inside unstructured messages regardless of the specific financial provider.

The Evolution of the Project

The development of Gemma-SME Ledger can be summarized in three stages:

Initial Concept
      │
      ▼
M-Pesa SMS → Structured Financial Data
      │
      │
      ▼
Initial Model
~200 M-Pesa-focused examples
      │
      │
      ▼
Semifinal Evaluation
      │
      ├── Good performance on familiar patterns
      │
      └── Weakness on broader domains / capabilities
      │
      ▼
Training Strategy Redesign
      │
      ├── ~20,000 examples
      ├── Banking messages
      ├── Pochi / Paybill / Till
      ├── Fuliza / loans
      ├── Transfers
      ├── Reversals / failures
      ├── Diverse message formats
      └── Capability instruction tuning
      │
      ▼
Current Direction
General Financial Transaction Intelligence
      │
      ▼
Offline / On-Device Deployment

This iteration was particularly important because it demonstrated that data diversity and task coverage can be more valuable than simply scaling the number of model parameters when working with small language models.

How I Built It

The system follows a multi-stage pipeline:

Financial Transaction Messages
              |
              v
     Fine-tuned Gemma 3 270M
              |
              v
       Structured JSON
              |
              v
      Validation Layer
              |
              v
       Pandas Financial Ledger
              |
              v
   Deterministic Python Analytics
              |
              v
       Financial Profile
              |
              v
     Gemma 3 270M
              |
              v
   Financial Insights & Guidance

The first stage uses the fine-tuned Gemma model to understand transaction messages and extract structured information such as:

  • Entity
  • Transaction amount
  • Transaction type
  • Income or expense direction
  • Transaction category
  • Transaction date
  • Transaction reference
  • Account or M-Pesa balance
  • Transaction status

For example, an unstructured transaction message can be transformed into a record such as:

{
  "entity": "Naivas",
  "amount_kes": 1250,
  "transaction_type": "payment",
  "direction": "expense",
  "category": "food",
  "balance_kes": 11590
}

The exact fields can vary according to the transaction type and extraction schema.

Multiple transactions are then collected into a local Pandas DataFrame that acts as a lightweight financial ledger.

The Hybrid Intelligence Architecture

A major architectural decision was to not ask the 270M parameter model to perform every part of the financial workflow.

The system deliberately divides responsibilities between the language model and deterministic software.

Gemma handles language understanding

The model is responsible for tasks such as:

  • Understanding transaction messages
  • Extracting entities
  • Extracting amounts
  • Extracting balances
  • Identifying dates
  • Identifying transaction types
  • Identifying transaction status
  • Classifying transaction direction
  • Producing structured JSON
  • Answering capability-oriented questions
  • Interpreting computed financial information

Python handles deterministic computation

Python performs operations where exact numerical correctness matters:

  • Total income
  • Total expenses
  • Net cash flow
  • Current balance
  • Spending by category
  • Spending by entity
  • Main income sources
  • Average transaction size
  • Expense rate
  • Surplus rate
  • Income-to-expense ratio
  • Largest expenses
  • Transaction aggregation
  • Balance consistency checks
  • Duplicate detection
  • Financial health signals

For example, instead of asking the small model to calculate net cash flow from dozens of transactions, the system can provide:

Total income: KES 25,000
Total expenses: KES 16,000
Net cash flow: KES 9,000
Surplus rate: 36%
Top spending category: Food
Top spending entity: Naivas

Gemma can then focus on interpreting those results and communicating them naturally to the user.

This separation significantly reduces the reasoning burden placed on the small model.

Fine-Tuning and Model Optimization

The base model is Gemma 3 270M, fine-tuned using LoRA (Low-Rank Adaptation).

The original training objective was narrowly focused:

M-Pesa SMS
     |
     v
Structured transaction JSON

The semifinal evaluation demonstrated that this narrow specialization was insufficient for broader financial transaction intelligence.

The training objective was therefore expanded.

The new approach is closer to:

                 Financial Messages
                         |
       ┌─────────────────┼──────────────────┐
       |                 |                  |
       v                 v                  v
   Mobile Money       Banking          Payments
       |                 |                  |
       └─────────────────┼──────────────────┘
                         |
                         v
             Financial Understanding
                         |
              ┌──────────┴──────────┐
              |                     |
              v                     v
       Structured Output      Capability QA

The expanded dataset teaches the model not only how to extract transactions, but also how to handle different financial message structures and explain its intended capabilities.

After fine-tuning, the model was merged, converted to GGUF, and quantized to Q4_K_M for efficient local inference using llama.cpp.

Training Data: From 200 to ~20,000 Examples

The most significant change after the semifinal evaluation was the training dataset.

Initial model

~200 examples

Mostly:
M-Pesa transaction messages

This was useful for proving that a 270M model could learn the extraction task, but the distribution was too narrow.

Current model

~20,000 examples

                    ┌── M-Pesa
                    ├── Pochi
                    ├── Paybill
                    ├── Till
                    ├── Banking
                    ├── Transfers
                    ├── Fuliza
                    ├── Loans
                    ├── Reversals
                    ├── Failed transactions
                    ├── Different message formats
                    └── Capability instructions

A large portion of the expanded data is synthetically generated.

Synthetic generation made it possible to deliberately create variation across:

  • Transaction amounts
  • Balances
  • Dates
  • Times
  • Entities
  • Merchants
  • Transaction references
  • Transaction states
  • Message structures
  • Financial providers
  • Transaction categories
  • User questions

This is particularly valuable for a small model because training diversity helps reduce over-specialization to a handful of message templates.

Capability Instruction Training

Another lesson from model evaluation was that being able to perform a task is different from being able to explain the task it can perform.

For example, asking the model:

What can you do?

could previously produce an incomplete or poorly grounded response.

The updated training data therefore includes capability-oriented instruction examples.

These teach the model to correctly describe its intended functionality, including its ability to:

  • Understand financial transaction messages
  • Extract structured financial information
  • Identify transaction entities
  • Extract amounts and balances
  • Identify transaction dates
  • Classify transaction types
  • Recognize transaction status
  • Handle different financial message formats
  • Produce structured outputs
  • Support downstream financial analysis

This makes the model more useful as an actual financial intelligence component rather than simply a transaction parser.

Why Synthetic Data?

Training a small model to generalize across many financial-message formats requires a large and controlled dataset.

Real financial transaction records are sensitive and difficult to obtain at scale.

Synthetic data provides a way to generate realistic transaction-language patterns without relying on people's actual financial histories.

The generator can systematically vary:

Provider
   +
Transaction type
   +
Amount
   +
Entity
   +
Date/time
   +
Balance
   +
Status
   +
Message format

This creates thousands of combinations while avoiding real customer financial information.

The goal is not to simulate individual people's financial lives.

The goal is to teach the model the language and structure of financial transactions.

Dataset Provenance

The SME-Ledger V2 synthetic dataset was generated using a dedicated data-generation pipeline.

The generation process is documented through the Kaggle notebook:

SME-Ledger Data Generator

https://www.kaggle.com/code/wangapa106g/sme-ledger-data-genarator/output

The dataset-generation process covers the transaction domains and instruction categories used for model training.

The repository also maintains representative dataset samples and provenance documentation under:

provenance/
├── README.md
└── dataset_sample.jsonl

The provenance documentation records the dataset version, generation methodology, categories, splits, generation seed, synthetic-data policy, and other information necessary to understand how the training data was produced.

What I Learned From the Semifinal Evaluation

The semifinal stage changed the direction of the project in an important way.

The initial instinct was:

If the model is small, perhaps it needs more model capacity.

The evaluation suggested a different lesson.

The model was not necessarily failing because it had only 270M parameters.

It was also being asked to generalize beyond what it had been taught.

The original dataset contained only around 200 M-Pesa-focused examples. That made it difficult for the model to learn the broader concept of financial transaction language.

The response was therefore to improve the training distribution before increasing model size.

This resulted in a new development principle:

For constrained AI, improving what the model learns can be as important as increasing how large the model is.

This is particularly relevant to edge AI, where increasing parameter count has direct consequences for:

  • RAM consumption
  • Model size
  • Loading time
  • Inference speed
  • Battery usage
  • Hardware requirements

A more carefully trained small model can therefore be a more practical solution than simply deploying a much larger model.

Why On-Device AI Matters

The project is ultimately about more than reducing model size.

Financial transaction data is sensitive.

Sending a user's complete financial history to a remote server for every financial question introduces:

  • Privacy concerns
  • Connectivity requirements
  • Data costs
  • Cloud infrastructure costs
  • Latency
  • Dependency on third-party AI services

Gemma-SME Ledger explores an alternative:

Financial Data
      |
      v
User's Device
      |
      ├── Local Model
      ├── Local Ledger
      ├── Local Analytics
      └── Local Insights

The objective is to keep sensitive financial information as close to the user as possible while still providing useful AI-powered interaction.

Designed for Constrained Hardware

The system targets the ADTC laptop environment rather than assuming access to a high-end GPU.

The model uses:

  • Gemma 3 270M
  • LoRA fine-tuning
  • GGUF conversion
  • Q4_K_M quantization
  • llama.cpp
  • CPU-oriented local inference

The target environment is an 8 GB RAM laptop.

This constraint influenced the entire design.

Rather than trying to place a large model on the device, the system combines:

Small LLM
    +
Deterministic Software
    +
Carefully Designed Training Data
    +
Quantization
    +
Efficient Runtime

The result is a system designed around the hardware that users may already have.

What I Built

The final concept is a local financial intelligence pipeline:

             Financial Transaction Messages
                         |
                         v
             ┌───────────────────────┐
             │   Gemma 3 270M GGUF   │
             │   Local Extraction    │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │   Structured JSON     │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │   Validation Layer    │
             │   + Normalization     │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │    Pandas Ledger      │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │ Deterministic Python  │
             │      Analytics        │
             ├───────────────────────┤
             │ Income                │
             │ Expenses              │
             │ Cash Flow             │
             │ Spending Patterns     │
             │ Balance Checks        │
             │ Financial Signals     │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │   Financial Profile  │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │   Gemma 3 270M        │
             │ Local Interpretation  │
             └───────────┬───────────┘
                         |
                         v
             ┌───────────────────────┐
             │ User Guidance / QA    │
             └───────────────────────┘

The result is a deliberately small, privacy-conscious financial intelligence system.

From Kenyan M-Pesa Problem to Broader Financial Intelligence

The project began with a distinctly Kenyan observation:

Your financial history may already be sitting inside your SMS inbox.

M-Pesa provided a powerful real-world example of this problem.

But the underlying technology does not need to be restricted to M-Pesa.

A bank notification, wallet notification, merchant payment message, mobile-money notification, or transfer confirmation can all contain the same fundamental information:

WHO?
  ↓
DID WHAT?
  ↓
HOW MUCH?
  ↓
WHEN?
  ↓
WHAT WAS THE STATUS?
  ↓
WHAT IS THE RESULTING BALANCE?

The wording and format change between providers.

The financial concepts remain similar.

This is why the expanded training strategy deliberately introduced diverse financial transaction messages.

The long-term objective is therefore to build a provider-agnostic financial transaction intelligence layer, where new providers and message formats can be added through data and targeted fine-tuning rather than redesigning the entire system.

M-Pesa is where the problem was discovered.

Financial transaction intelligence is where the project is heading.

Future Direction

The current system focuses on understanding financial transaction messages and converting them into structured financial information.

The next stage can extend this foundation toward:

  • Automatic SMS ingestion
  • Transaction deduplication
  • Balance consistency checks
  • Fraud and anomaly detection
  • Cash-flow forecasting
  • Financial health scoring
  • Loan affordability analysis
  • SME bookkeeping
  • Credit-readiness signals
  • SACCO decision support
  • Financial institution integrations
  • Multi-provider transaction understanding
  • Additional African financial messaging formats
  • Android on-device deployment

The broader vision is:

Transaction Messages
        |
        v
Structured Financial Data
        |
        v
Personal / SME Ledger
        |
        v
Cash-Flow Intelligence
        |
        v
Financial Health Signals
        |
        v
Credit Readiness
        |
        v
Privacy-Preserving Financial Intelligence

The Core Lesson

The most important lesson from building Gemma-SME Ledger was not simply that a 270M parameter model can run on a laptop.

It was learning how to design around the limitations of a small model.

The semifinal evaluation showed that narrow training could limit generalization.

Instead of immediately reaching for a larger model, I expanded the training distribution, introduced multiple financial domains, diversified transaction formats, and added capability-oriented instruction examples.

The architecture then separates language understanding from deterministic financial computation.

The result is a system where:

Training Data
      +
Small Specialized Model
      +
Deterministic Software
      +
Quantization
      +
On-Device Inference

work together as one financial intelligence system.

The central idea is simple:

Don't make the small model do everything. Build the system so that the small model does what it does best—and teach it a sufficiently broad representation of the problem.

That is the principle behind Gemma-SME Ledger.

Built With

Share this project:

Updates