We’re architecting a bank reconciliation process that needs to pull transaction data from multiple legacy banking systems. Some systems have APIs (though poorly documented), while others are mainframe-based with only screen access.
I’m torn between two approaches: using RPA bots to navigate screens and extract data versus pushing for API development where possible and using Integration Hub connectors. The RPA approach gets us to market faster, but I’m concerned about long-term maintenance. Direct API integration is cleaner architecturally but requires significant effort from banking system owners who are resource-constrained.
What factors should drive this decision? Has anyone dealt with similar trade-offs in financial services integrations? Interested in hearing experiences with both approaches, particularly around error handling and scalability in production.
Error handling is where this gets interesting. RPA error handling is fundamentally different from API error handling. With APIs, you get structured error responses, retry logic is straightforward, and transaction boundaries are clear. With RPA, you’re dealing with visual recognition failures, unexpected popup windows, session timeouts, and screen navigation errors. We built extensive error recovery logic into our RPA bots - screenshot capture on failure, automatic retry with exponential backoff, fallback to manual queue when bot can’t proceed. It works, but it’s complex. API errors are just easier to reason about and handle programmatically.
From a pure scalability perspective, APIs win hands down. RPA bots have inherent limitations - they consume virtual machines, struggle with concurrent execution, and break when UI changes. That said, for legacy systems compatibility where APIs don’t exist, RPA is often the only viable option. In banking, I’ve seen mainframe systems that haven’t been updated in 20 years and never will be. For those, RPA is a pragmatic choice. But for any system with a documented API, even a poor one, I’d invest in the Integration Hub connector. You can always wrap a poorly designed API with a service layer to make it more consumable.
The error handling point resonates. We’re processing thousands of transactions daily, so reliability is critical. How do you handle the scenario where a screen layout changes in a legacy system? Does that bring everything to a halt?
Screen changes are definitely a risk. We mitigate this with automated bot health checks that run every hour and alert us immediately if navigation fails. We also maintain version-specific bot configurations so we can quickly switch to an updated bot when screens change. The key is having a robust monitoring and alerting strategy. Without it, you’re flying blind.