SMS parsing API: turn bank transaction alerts into structured data and credit insights

What an SMS parsing API does

This is the cheapest high-coverage financial data source in the markets FinArt serves. In India, Sri Lanka and the GCC, transaction SMS reaches essentially every customer who has a bank relationship and a phone — including customers with no credit file, no aggregator-connected account and no digital statement history. It arrives within seconds of the transaction, it spans banks, cards, wallets and lenders simultaneously, and crucially you do not need to own the platform that generates it. Unlike e-commerce history, delivery data or in-house wallet transactions, SMS is alternative data you can use without first building the service that produces it.

What you get back

Request and response

The integration surface is deliberately small. You send a message payload; you read back a transaction object. The example below is an Indian UPI debit alert.

Request

POST /v1/parse
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "message_id": "c1f9a4e2",
  "sender": "AD-HDFCBK",
  "body": "Sent Rs.1249.00 From HDFC Bank A/C XX4821 To SWIGGY On 05/09/26 Ref 528374912345 UPI:swiggy@icici Avl Bal Rs.18422.65",
  "received_at": "2026-09-05T14:32:10+05:30",
  "country": "IN",
  "locale": "en-IN"
}

Response

{
  "message_id": "c1f9a4e2",
  "is_transaction": true,
  "message_class": "transaction",
  "type": "debit",
  "amount":      { "value": 1249.00, "currency": "INR" },
  "institution": { "name": "HDFC Bank", "code": "HDFC", "country": "IN" },
  "instrument":  { "type": "savings", "mask": "XX4821" },
  "counterparty":{ "raw": "SWIGGY", "normalised": "Swiggy", "vpa": "swiggy@icici" },
  "channel": "UPI",
  "reference": "528374912345",
  "occurred_at": "2026-09-05T00:00:00+05:30",
  "balance_after": { "value": 18422.65, "currency": "INR" },
  "category": { "id": "food_delivery", "label": "Food & Dining", "confidence": 0.97 },
  "confidence": 0.99
}

The same schema, a different market

A Saudi mada card purchase in Arabic returns the identical object shape — only the values change. That is the point of the normalisation layer: your downstream feature pipeline, ledger or scorecard does not need per-country branching.

{
  "message_id": "7ab30c11",
  "is_transaction": true,
  "message_class": "transaction",
  "type": "debit",
  "amount":      { "value": 87.50, "currency": "SAR" },
  "institution": { "name": "Al Rajhi Bank", "code": "RJHI", "country": "SA" },
  "instrument":  { "type": "debit_card", "mask": "**4417", "scheme": "mada" },
  "counterparty":{ "raw": "PANDA HYPERMARKET", "normalised": "Panda" },
  "channel": "card_pos",
  "occurred_at": "2026-09-05T19:41:00+03:00",
  "category": { "id": "groceries", "label": "Groceries", "confidence": 0.95 },
  "language": "ar",
  "confidence": 0.98
}

A message that is deliberately not a transaction

{
  "message_id": "0d47fe93",
  "is_transaction": false,
  "message_class": "otp",
  "excluded_reason": "one_time_password",
  "confidence": 0.99
}

One-time passwords, promotional offers, delivery updates and service notices are filtered at classification time and never reach your transaction store. Handling OTP traffic correctly is both a security requirement and a regulatory expectation across these markets.

Core response fields

Field availability depends on what the sending institution actually puts in the message. Balance, reference and category are populated where present. Exact field lists, error codes, batch endpoints and rate limits are covered in the technical documentation, which is released once a commercial agreement is in place.

Beyond parsing: the derived insights layer

This is usually the part that decides the business case. A transaction feed is an input; an income estimate, a repayment-behaviour profile and a product-intent score are decisions you can act on the same day, without hiring a feature-engineering team first.

Illustrative insights response

Computed over a rolling window rather than a single message. The exact catalogue, window and field names are agreed per engagement — this shows the shape.

{
  "user_ref": "u_8f21c04b",
  "window": { "from": "2026-03-01", "to": "2026-08-31", "months": 6 },
  "income": {
    "estimated_monthly": { "value": 84500, "currency": "INR" },
    "regularity": "salaried_regular",
    "credits_observed": 6,
    "confidence": 0.91
  },
  "payment_behaviour": {
    "emi_payments_observed": 17,
    "on_time_ratio": 0.94,
    "overdue_events": 1,
    "penalty_or_bounce_events": 0
  },
  "obligations": {
    "active_emi_count": 2,
    "estimated_monthly_outflow": { "value": 12400, "currency": "INR" }
  },
  "intent": [
    { "product": "personal_loan", "score": 0.72, "signals": ["loan_enquiry_messages", "rising_card_utilisation"] },
    { "product": "investment",    "score": 0.55, "signals": ["recurring_surplus", "existing_sip_debits"] },
    { "product": "insurance",     "score": 0.38, "signals": ["policy_renewal_due"] }
  ],
  "spending": {
    "monthly_average": { "value": 41200, "currency": "INR" },
    "top_categories": ["groceries", "fuel", "food_delivery"],
    "trend": "stable"
  },
  "liquidity": {
    "median_balance": { "value": 23800, "currency": "INR" },
    "low_balance_days_pct": 0.12
  }
}

The insight catalogue is extensible: additional signals are built for specific underwriting, collections or cross-sell objectives during the engagement. Insights can be delivered as a scored object like the above, or as raw model-ready features for teams that prefer to own the scorecard.

This maps directly onto what the research in the evidence section measured: income regularity, overdue frequency, EMI burden and spending stability were among the highest-contribution features in a model that outperformed traditional credit scores by 33%.

How the parsing engine works

Two layers, because neither alone is sufficient at national scale.

1. Sender-template extraction. Maintained pattern models per sender header — AD-HDFCBK, SBIINB, Al Rajhi, BenefitPay and so on. Fast, deterministic and exact for the senders that generate the overwhelming majority of message volume.
2. Named entity recognition fallback. Extractions from the template layer become training labels for an NER model that generalises to senders no template covers — small savings banks, regional cooperatives, new wallets, a bank that shipped a template change last night. This is what keeps coverage from collapsing at the long tail, and it is the same architectural pattern used in the peer-reviewed research cited below.

Around those two layers sit classification (is this even a transaction?), currency and numeral normalisation, institution resolution, merchant normalisation and category assignment.

Three deployment models

The engine is stateless per request and makes no outbound calls during parsing, which is what makes the in-VPC and on-device options straightforward. Throughput and latency benchmarks for your expected volume are shared during evaluation.

SMS parsing vs the alternatives

These are not mutually exclusive. Most sophisticated teams use SMS parsing for breadth and immediacy, and an aggregator or statement pull for depth on the accounts that matter most. The honest comparison:

On building it yourself

Every serious product team in these markets has considered it, and the first version is genuinely not hard — a few hundred regular expressions covering the top ten banks will get you a demo. The cost is not the build; it is that bank templates drift continuously, wallets and rails launch, and each market you expand into resets the work. That maintenance lands on the same engineers you hired to build your actual product, and a template change that silently stops producing transactions is a class of bug that is very hard to notice from the inside. FinArt's own consumer app runs on this engine, which means template drift shows up in FinArt's product before it shows up in yours.

What teams build with it

The evidence that SMS data predicts credit risk

This is no longer only a vendor claim. A June 2026 working paper — “Signals from SMS: Alternative Data and Distributional Effects in Credit Scoring” by Seung Hyeong Lee, Kenneth Ryu and Jaehyeok Shin — analysed 22 million loan applications at an Indian fintech lender and measured, source by source, how much SMS-derived data actually contributes to predicting delinquency.

Where the gains actually land

The leave-one-out analysis is the most useful result for anyone deciding what to integrate. Removing SMS data cost the model 3.10 percentage points of AUROC — roughly double the 1.53pp cost of removing credit bureau data, and an order of magnitude more than removing application, service or survey data. In the authors' framing, SMS and bureau data are complements that cannot substitute for each other: each contributes information the other does not hold.

Source: Lee, Ryu & Shin (June 2026), Table 3. Delinquency is defined as 30+ days past due on any of the first three EMIs.

Credit access, measured

Across 2.7 million approvals in the study, 45,012 loans went to new-to-credit borrowers with no bureau score, and 2.68% of all loans went to applicants who were either unscored or subprime — borrowers who would in practice have been declined in a bureau-only market. The paper also notes the methodological point that matters most for regional expansion: because the extraction method depends only on the alert the bank already sends, it “is generalizable in different settings and can be applied in other countries where SMS is used as a channel for transaction alerts.”

The finding your model-risk team will want to read

We would rather you hear this from us than find it in review. The same paper reports that the benefits of alternative-data scoring skew toward financially advantaged applicants — not because of algorithmic bias, the authors are explicit on this, but because more extractable financial signal exists in their message history in the first place. Applicants with a college education ranked on average 7.3 percentile points higher under the alternative score than under the traditional one. Asking for more data does not fully close the gap either: less advantaged applicants were measurably less willing to share bank statements when asked.

The practical implication for anyone deploying this: treat signal density as a monitored model input. Track coverage and extraction volume by applicant segment, and be careful about policies that implicitly penalise a customer for having a sparse message history rather than a poor one. We would rather help you instrument that from day one than have it surface in a fair-lending review two years in.

FinArt was not a party to this research and the study analysed a different lender's stack. We cite it because it is the most rigorous public measurement of what SMS-derived financial data is worth in a credit model, and because its conclusions about coverage disparity should inform how the data is used.

Markets: India, Sri Lanka and the GCC

FinArt concentrates on markets where transaction SMS remains the dominant real-time financial notification channel, mobile penetration is near-universal, and bureau coverage leaves a large, creditworthy population invisible. The parsing approach is sender-driven rather than integration-driven, so adding an institution means adding message samples, not negotiating a new data connection.

What differs by market, and why it matters

• India is the highest-volume and most fragmented market: hundreds of banks and cooperatives, an enormous UPI transaction count, sender headers registered under TRAI's DLT framework, and a very large credit-unserved population. The 2025 TransUnion CIBIL figures the research cites put roughly 451 million Indian adults in the credit-unserved category and a further 273 million underserved. Volume and template churn here are what the two-layer architecture exists for.
• Sri Lanka combines high mobile-banking penetration with limited bureau depth, and messages are frequently issued in Sinhala or Tamil alongside English — script handling is not optional.
• The GCC markets share a pattern that makes SMS unusually valuable: a large expatriate workforce with short domestic credit histories, salary paid through wage-protection systems that generate reliable credit alerts, heavy remittance outflow, and Arabic-first or bilingual message formats with their own numeral and date conventions. A worker three months into a UAE or Saudi posting has almost no bureau file and a perfectly legible income and spending record sitting in their inbox.
• Domestic card and instant-payment schemes are proliferating. Jaywan, Himyan, mada, sarie, Fawran and Aani all generate their own alert formats, and several are recent. Coverage of the newest rails is exactly where an in-house regex library falls behind first.

Exact sender and template coverage is confirmed empirically, against a sample of your own real messages, during evaluation — not asserted from a marketing page. Any senders the benchmark shows as uncovered are added through an agreed extension process before production rollout.

Security, privacy and regulatory fit

You remain the data controller for your customers' data. FinArt processes it on your instructions under a data processing agreement, and the deployment models exist precisely so that raw message text can stay inside whatever boundary your regulator, your risk committee or your own privacy promise requires.

• Consent stays with you. The API operates on messages your customer has already received and permitted your app to read. There is no credential sharing and no scraping.
• Data minimisation is a deployment choice. With the on-device SDK, raw message text never leaves the handset; you receive only the structured result, or only the derived features you specify.
• Residency is a deployment choice. The containerised engine can run inside your own VPC or data centre where localisation rules or internal policy require it.
• OTPs are excluded by design, not by convention — they are classified out before extraction.
• Retention is contractual. Retention windows, deletion timelines, sub-processor disclosure and audit rights are set in the DPA rather than left to platform defaults.

Applicable data protection regimes

This table is orientation, not legal advice, and these regimes change. Confirm your own obligations with counsel — particularly on cross-border transfer, consent basis and any sector-specific rules your regulator applies to lending or customer data.

How an engagement runs

1. Scoping call. Markets, expected monthly message volume, deployment model, and what you are actually trying to predict or build.
2. Independent quality check. Before any paperwork, you can judge the engine for yourself through FinArt's consumer app, which runs on it — see below.
3. Commercials and agreement. Volume-based pricing, the commercial agreement, data processing agreement, retention terms and support SLA. Technical documentation and API access are released at this point, not before.
4. Documentation and integration. API reference, field definitions and integration guidance. The surface area is small — you post a message and read back one object — so most teams are calling the API within days.
5. Validation on your own messages. Coverage and field-level accuracy are checked against a sample of your real message traffic, so you are working from measured numbers rather than a claim. Senders that come back uncovered are added before rollout.
6. Production rollout. With an agreed process for template drift, new senders and new markets as you expand.

A useful due-diligence shortcut: FinArt's own consumer expense-tracking app on Android and iOS runs on this same engine. Install it, connect your own messages, and verify parsing quality and coverage yourself before you sign anything. This is how most of our partners have run their technical due diligence.

Why FinArt

Related reading

• Bank SMS parser solution: converting transaction messages into structured data
• Partner with us — influencer and affiliate programme
• Privacy policy and terms of use

Last updated: 7 September 2026 · Written and maintained by the FinArt team · support@finart.app