It’s time to revisit the order management (pre-processing) concept
Where is your bank on the order management (or pre-processing, or initiation management – whichever you prefer) maturity scale? Are you running your order management on legacy technology as a routing/integration layer or are you seeing this as a key strategic layer which allows you to run your payments as a business and dynamically bundle products?
Order management is something many banks are keen to implement or modernise right now and it’s an area that I have always believed to be instrumental for a modern payments architecture. So on the back of my esteemed colleagues’ recent blog posts Vertical thinking: Why banks need to decouple their payments processing value chain and The value of a “Payments Reference Architecture” in driving payments transformation, I’d like to chip in and add my thoughts on order management.
Why now is – and has been – the time to implement strategic order management
The concept of order management has been around for almost two decades. I believe it was actually during my time at Clear2Pay that we coined the term – inspired by the usage of the term in securities processing. Banks have always seen it as an area with the potential to add great value, but it’s proven to be ever so challenging to implement order management in a strategic manner.
At best, Tier 1 banks implemented an integration layer (or isolation layer, same thing) – on the back of the Service Oriented Architecture wave in vogue – with technologies heavily used and marketed at the time. Most of these layers turned out to be glorified routing layers (even if they in theory supported things like ‘least or fast cost routing’) and never lived up to the promise of order management being much more strategic. What makes things worse is that those very same technologies, think of IBM Message Broker (aka FTM), Tibco or Oracle Tuxedo, have now become outdated and not easy to support.
It wasn’t just technology, but also regulatory initiatives like tactical ISO20022 migration, PSD2, SEPA and so on that prevented banks from implementing order management in a strategic way, because they were always heads down working on the next must do tactical initiative. Therefore, we don’t think anything material has been done with this concept.
So, banks are now at risk of finding themselves with aging technology at a time when the Cloud has matured, APIs have become the standard, ISO20022 is – finally – well understood and Open Banking is a regulatory requirement.
What you can expect to get out of order management done right
The vision has always been that order management is implemented as a single layer, enabling ‘progressive transformation’ by
- Simplifying many thick Channels to the point of thin Channels (or just APIs for that matter). We still see lots of payments functionality duplicated across channels, which inhibits an omnichannel approach with consistent service levels.
- Making it easier to add new payment rails (and decommission old ones), so you don’t need to re-strategise each time something like FedNow or the NPA pops up.
- Managing all transactions based on client profiles (customer / processing settings)
- Being able to introduce value-added services such as aggregation, netting, pooling and FX from the bank or third parties (fintechs).
Order management should achieve all of the above with one underlying data model for any payment flow, which in turn allows for a buzzword compliant data strategy (AI, monetisation, machine learning).
How Icon can support anything from target architecture and roadmap to technology
We help banks build a pragmatic business case based on relevant use cases like support for Platform Clients (e.g. App Stores pay in/pay out to third parties) or SMBs (including working capital management and factoring), resulting in spending less, making more and/or not ending up in court.
This approach should result in a clear target architecture and actionable roadmap, supported across the bank (business/ops/it).
From a technology perspective we believe that clients should have full control over this layer (and everything else for that matter), given the strategic importance and therefore the need not to be tied to a vendor. A low-code approach does not just help with that but also significantly increases the speed to market as detailed in this new Celent report: Using Low Code To Accelerate Payments Innovation. This boils down to leveraging code, not config, as a cornerstone of your tech strategy, allowing your bank to create your own ‘secret sauce’. Working at Icon Solutions, it should come as no surprise to you that we believe the Icon Payments Framework (IPF) software development kit is a valuable accelerator in this process.
Wherever you are on your payments transformation journey, why not have a chat with me or my colleagues and we’d also be happy to share some insights from a few interesting PoCs.