2 ms·
Yeah this seems like something that you'd be able to do anywhere, but some banks don't support this kind of export, or they don't allow you to export beyond a c
by spiked 10mo ago
Yeah this seems like something that you'd be able to do anywhere, but some banks don't support this kind of export, or they don't allow you to export beyond a certain date in the past. It started as a side project for a contractor buddy who needed 300 pages and 4 years of transaction data imported into Quickbooks, and his bank actually SENT him the pages in the mail. eyeroll. So, of course scanned documents have no export option. In addition, some banks actually restrict bulk exports, and connectors like Plaid or Finicity don't always cover historical data.
As for security, totally fair concern. I tried to cover as much as I could here: https://statementstosheets.com/security https://statementstosheets.com/security
Some key points: I'm using secure authentication, https enforecment, sandboxed processing within GCP containers, automatic deletion of user data, a lifecycle policy for data that does get uploaded, and secure payment processing with Stripe.
Genuinely curious from a security standpoint — what would you want to see on a site like this before trusting it with financial docs?
- jaggs 10mo agoI'd want to see it as a local standalone app.
- codingdave 10mo agoOn your key points, you have a web site that says you do all those things. But so would a malicious actor. You'd need some 3rd party audit to validate you, or even better, do not sell this as B2C, create a B3B version so that banks are your direct customers, and individuals access your product through their existing online banking. Basically, fix the feature gap in banking by selling them the missing parts. (Or, as the other comment says as I'm writing this - just have it run locally. That works quite well, too.)