Turning transaction SMS into structured financial data

A gap in convenient transaction access

I wanted a reliable way to bring transaction details from different accounts into one place. In my experience, open banking and aggregator services did not provide a convenient route to all the transaction data I needed. That left a simple question: could the bank notifications already arriving on a phone become a useful, structured source?

SMS is not a clean data feed. A phone receives marketing messages, balance alerts, security codes and transaction notifications in formats that vary by institution and merchant. The useful signal first has to be identified, separated from noise and interpreted consistently.

Turn incoming messages into transaction records

The prototype follows a staged pipeline. It captures messages on Android, determines which ones are transactional, checks for duplicates, parses the relevant content and makes the resulting records available through an API and an MCP interface. Each stage is separate so that an error in classification or parsing can be investigated without treating every message as valid financial data.

This structure also creates a place to improve the system incrementally. Transaction identification, duplicate handling and message parsing are distinct problems, with different failure cases and different tests.

• Capture eligible SMS messages on Android
• Classify transactional messages and ignore unrelated SMS
• Detect repeated notifications before creating duplicate records
• Parse transaction details into structured data
• Expose the resulting records through API and MCP interfaces

A working path, with parsing edge cases still visible

The early proof of concept ran locally on my MacBook Air and established an ingestion path with a running service. Testing exposed a Starbucks notification format that the parser did not handle correctly. That is a useful failure: message formats are not a stable schema, so the parser needs explicit handling for known variations, safe treatment of unknown formats and regression tests as new examples are added.

The work is still in progress. The current prototype demonstrates the direction, but it is not yet a finished public product and its parsing coverage should not be mistaken for universal bank or merchant support.

Android access is a real product boundary

The listener depends on access to incoming SMS. Android can support this kind of app with the appropriate user consent and platform permissions. iOS does not provide third-party apps with general access to read the user's Messages inbox, so the same passive listening model cannot be offered there.

That makes platform choice part of the product definition, rather than an implementation detail. Any route to iOS would need a different user-controlled input method and would not be equivalent to background SMS listening.

The next problem is making it safe to use

Transaction messages can reveal sensitive personal and financial behaviour. Moving from a local experiment to a public service requires a deliberate decision about what stays on the device, what is transmitted, where records are stored, how each user is isolated and how access is granted or revoked.

Those decisions are still open. Before a public release, I need to settle the data-flow and threat model, minimise the information collected, define retention and deletion, protect transport and stored data, secure API and MCP access, and test how consent and Android permissions are explained. I am evaluating the right product architecture with privacy and cybersecurity as core constraints, not as later additions.

• Map every data flow from SMS capture to API or MCP response
• Decide what processing and storage remain on device
• Define consent, access control, retention and deletion
• Threat-model message parsing, credentials and exposed interfaces
• Validate Android distribution and permission requirements before release

A useful signal is not yet a trustworthy product

This project is an exploration of a practical alternative data path, not a claim that SMS can replace open banking or formal account aggregation. Its value will depend on the accuracy of parsing, the transparency of its limitations and the care taken with sensitive data.

The next stage is to improve parser coverage and test the full ingestion-to-interface path, then choose a privacy-preserving deployment model that can be responsibly offered to other people. Until those choices are validated, the project remains in development.