Comments on: Batch Mode http://cuinnovators.com/blog/batch-mode/ At CU Innovators, we help credit unions, CUSO's, and service providers create meaningful products and services for their members and clients. Fri, 30 Jul 2010 02:36:42 +0000 hourly 1 By: Ben http://cuinnovators.com/blog/batch-mode/comment-page-1/#comment-622 Ben Tue, 02 Jun 2009 05:44:39 +0000 http://blog.cuemployee.com/?p=342#comment-622 I'd suggest the biggest reason batch is still so common is demand - so often batch isn't ideal, but it is "good enough" for a lot of things. So what can CUs do? Demand it, ask for it, include it in RFPs, raise the priority. I see it all the time that real time is an "optional requirement" or "nice to have" - until the demand is there, vendors just won't undertake the (sometimes huge) effort to provide support. My next comment would be that all too often the financial institution often can't make the business case that real time is necessary. In some cases, real time transactional processing might be available for a given need, but the support systems are all batch, and a single given need doesn't provide the FI with a strong enough business case to make all the other changes required to move to real time. All this being said, I believe a lot of service providers and technology vendors are trying to move toward real time transactional processing - a batch can always be broken down in to individual transactions, so in theory a real time process can rather easily support batch processing by breaking the batch in to transactions and reassembling them back in to a batch for output. I'm totally agree with you though - we can do amazing things with technology developed over the last 10 years. I can do more with my mobile phone today than I could with my PC 10 years ago - and it sometimes feels like the financial services industry is in the punch card age. Changing some of these things is like doing a simultaneous heart and brain transplant on the organization, which does and should scare everyone. I have to believe we're getting close to the point the benefits outweigh the risks and we'll start seeing the shift. As far as I'm concerned, it can't come soon enough. But where do we go from there? From real-time to future-time processing :-) I’d suggest the biggest reason batch is still so common is demand – so often batch isn’t ideal, but it is “good enough” for a lot of things. So what can CUs do? Demand it, ask for it, include it in RFPs, raise the priority. I see it all the time that real time is an “optional requirement” or “nice to have” – until the demand is there, vendors just won’t undertake the (sometimes huge) effort to provide support.

My next comment would be that all too often the financial institution often can’t make the business case that real time is necessary. In some cases, real time transactional processing might be available for a given need, but the support systems are all batch, and a single given need doesn’t provide the FI with a strong enough business case to make all the other changes required to move to real time.

All this being said, I believe a lot of service providers and technology vendors are trying to move toward real time transactional processing – a batch can always be broken down in to individual transactions, so in theory a real time process can rather easily support batch processing by breaking the batch in to transactions and reassembling them back in to a batch for output.

I’m totally agree with you though – we can do amazing things with technology developed over the last 10 years. I can do more with my mobile phone today than I could with my PC 10 years ago – and it sometimes feels like the financial services industry is in the punch card age. Changing some of these things is like doing a simultaneous heart and brain transplant on the organization, which does and should scare everyone. I have to believe we’re getting close to the point the benefits outweigh the risks and we’ll start seeing the shift. As far as I’m concerned, it can’t come soon enough. But where do we go from there? From real-time to future-time processing :-)

]]>