I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it.
For example, the docs show the product wants static creds for a Postgres database or signed URL for S3 bucket instead of leveraging best-practice service-to-service identity and access management.
Maybe you support what I want, and I didn't find it at first glance.
This either ...
(a) needs to support modern dynamic or token-based authentication (e.g. Oauth2.0 client credentials grant, JWT, or for enterprises ideally CSP native IAM in Azure/GCP/AWS such as share S3 by cross account bucket permissions policy instead of signed URL, etc.), or ...
(b) allow firms to operate this themselves so the spreadsheet is run in the firm's security context, no creds are shared and data never leaves.
As you are running in AWS, providing this to run in AWS IAM context could solve it, but it's likely worth your time collaborating closely with FS firms that have solved cloud-native infosec at scale for the world's most demanding regulatory environments such as GSIFIs/GSIBs, since if you can do that, it's secure for anyone. Similar for HIPAA or FedRAMP.
If your customers can be fully best practice compliant within these regulatory regimes without having to lower their standards or get exceptions to use you, then it's above the bar for pretty much everyone.
// Full disclosure: Although using all 3 of AWS, Azure, and GCP, I was an AWS CAB member for half a decade (as principal engineers you likely know what this means), with a native-AWS preference.