BankBotsBank: Screen-Scraping Bots for Bank Data, One Account at a Time

The Problem: Banks Without APIs

Most banks still do not offer public APIs for personal account data. The README points to Mondo (now Monzo) as a rare example of a bank that does. For everyone else, the only route to programmatic access is screen scraping. That means simulating a user in a browser, logging in, and parsing the HTML. BankBotsBank attacks this problem with a distributed model: each developer writes a bot for the bank where they hold an account. That avoids the need to open accounts at every bank just to test a scraper. The project is aimed at fintech developers who want to build applications on top of personal banking data without waiting for banks to open up. It is also a template for anyone who needs to scrape a site that requires a real user session, not just a public endpoint.

How the BBVA Bot Works

The first implemented bot targets the Spanish bank BBVA. According to the README, it returns a JavaScript object, or JSON through a web interface, containing the most recent transactions from the user's main account. The bot uses Nightmare, a browser automation library built on Electron, which is itself based on Chromium. Nightmare drives a real browser, so it can execute JavaScript, handle redirects, and render pages just like a human user would. The bot's code lives in src/bots/bbva/index.js. The README calls this file an example for developing bots for other banks. The data flow is straightforward: the bot logs in with user credentials, navigates to the account page, extracts the transaction table, and serializes it to JSON. Because it is a real browser, any change in BBVA's HTML structure or login flow will break the scraper, and the bot has no built-in resilience against that.

Getting It Running: Commands and Configuration

The repository includes a Dockerfile for deployment to AWS Elastic Beanstalk. The README explains that the Dockerfile shows how to use xvfb-run to run Nightmare on a machine without a graphical display. This is a key detail: Nightmare normally opens a visible browser window, but on a server you need a virtual framebuffer. The deployment setup is not a one-command install. You need to build the Docker image, push it to Elastic Beanstalk, and configure environment variables for the credentials, although the README does not list the exact variable names. To run the bot locally, you would clone the repository, install dependencies with npm, and then run the BBVA bot with your own credentials. The web form at the Elastic Beanstalk URL is the only public interface, and it is a test form, not a production endpoint. There is no mention of rate limiting, session management, or error handling beyond the basic scrape.

A Genuine Limitation: Fragility and Security

Screen scraping is inherently fragile. Any change to BBVA's website, from a new login step to a different CSS class, can break the bot. The README acknowledges this implicitly by framing the project as an interim solution until banks provide APIs. There is no test suite mentioned, no fallback for site changes, and no monitoring. A more serious issue is security. The bot requires the user's bank credentials. In the web form, a user enters their credentials into a third-party hosted service. That is a major trust barrier. The README does not discuss how credentials are stored, transmitted, or protected. For a fintech application, this is a deal-breaker. The project also does not handle two-factor authentication, which many banks now require. If your bank uses 2FA, this bot will not work without additional code that the repository does not provide. For any bank other than BBVA, you are on your own to write the bot.

The Alternative: Official APIs and Aggregators

The obvious alternative is to use a bank's official API when one exists. Mondo is cited in the README as the ideal. In Europe, PSD2 has forced banks to open APIs, so a project like this is largely obsolete for EU banks that comply. Another alternative is a commercial aggregator like Plaid or Yodlee, which already maintain scrapers for thousands of banks and handle the fragility, security, and compliance issues. The difference in approach is stark: BankBotsBank is a distributed, open-source effort where each developer maintains their own bot, while aggregators are centralized, closed-source, and professionally maintained. Aggregators charge fees, but they offer reliability and legal cover. BankBotsBank offers zero cost and full control, but you accept the maintenance burden and security risk. For a hobby project, the open-source route might be attractive. For a startup, the aggregator route is almost certainly safer.

Maintenance and License Implications

The repository has no recent releases and the last push is unknown, which suggests it is not actively maintained. The README is dated by references to a Hacker News discussion from 2016. The project is not archived, but that is a weak signal. The license is MIT, which means you can use, modify, and distribute the code freely, even commercially, as long as you preserve the copyright notice. There is no contributor guide or code of conduct in the README, so the maintenance model is unclear. The Dockerfile is a useful artifact, but it is tied to Elastic Beanstalk. If you deploy elsewhere, you will need to adapt it. The biggest maintenance cost is not the code itself, but the continuous effort to keep the scraper working against a moving target. Without a community actively updating bots, the project will rot. The README invites contributions, but there is no evidence of a community forming.

Who Should Use It and What to Verify First

This project is a starting point, not a finished product. If you are a developer who wants to learn how to scrape a bank site with Nightmare, the BBVA bot is a clear example. If you hold a BBVA account and want a quick way to pull your own transactions, the hosted form might work, but you should not enter your credentials into a random Elastic Beanstalk URL without knowing who controls it. For any other bank, you must write your own bot. Before relying on it, verify the repository's commit history to see if the bot has been updated recently. Check whether the BBVA site still has the same login flow. Test the bot with a dummy account if possible. Do not deploy it to production without adding your own error handling, logging, and credential management. The project's value is as a reference implementation, not as a service.

Editorial conclusion

Adopt BankBotsBank if you are a developer who wants to build a bot for your own bank, you accept the fragility of screen scraping, and you can handle your own credentials securely. Do not use it for production fintech services, for banks outside the few that have contributed bots, or if you need reliable, bank-sanctioned data. Before adopting, verify that your bank's login flow has not changed since the bot was last updated, check the repository's commit history for maintenance activity, and confirm that the MIT license and the lack of a formal support channel fit your risk tolerance. The project is a proof of concept, not a platform, and its value depends entirely on community contributions that have not been demonstrated at scale.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases