What would bank access let your product do?

Imagine you run an invoicing platform. Your customer creates an invoice, sends it and then leaves your software to check their bank account. Later, someone matches the incoming payment to the invoice and updates the records.

That sequence gives you somewhere useful to start an Open Banking conversation. Which parts could your product make easier? Could customers see relevant account activity alongside their invoices? Could the person receiving an invoice pay directly from their bank? How much work would still need human attention?

Account information services (AIS) provide access to account information with the customer’s consent. Payment initiation services (PIS) let a customer authorise a payment from their bank account. They offer different capabilities, with separate permissions and customer journeys.

For a software business, the opportunity is to use those capabilities at a moment when the customer already has a reason to act.

Consider a cash-flow product. Connected account information could give its users a starting point for understanding money coming in and going out. The product still has to turn that information into something useful: an explanation, a forecast or a decision the customer feels equipped to make.

For an invoicing platform, Pay by Bank could give the recipient a way to pay from the invoice. The commercial question is whether that journey improves payment completion, collection costs or the work involved in matching receipts.

These are hypotheses to test. Access to bank data creates an opportunity to build a useful feature. A payment option creates an opportunity to improve a transaction. The value depends on what happens when customers use them.

Start with a sentence your customer would recognise: “I want to know which invoices have been paid” or “I want to pay this and get on with my day.” That gives the project a clear purpose.