3 ms·

In retail banking I'm sure that this could be true. Working in investment banking, I never saw a single COBOL application, or had to have my C++/Java/$MODERNLAN

In retail banking I'm sure that this could be true. Working in investment banking, I never saw a single COBOL application, or had to have my C++/Java/$MODERNLANGUAGE code interact with one.

davedx 1y ago
Yeah when I worked in investment banking it was VBA and Java everywhere, never saw or heard of COBOL.
cyberpunk 1y ago
Corp bank here, everyone has rumours about COBOL systems but no one I've ever spoke to has seen, interacted or has any other evidence these really exist anymore either.
- charlieyu1 1y ago
  Me neither. But I asked for a bank statement from my old savings account a few years old and it took two weeks to print out, printed in monospace dot matrix. Or the betting company that I was a customer that suspends betting everyday 6:30am for an hour for daily maintainance. Ironically, they would accept bets for football matches played at the time, but the system was shut down. I suspect both are run on COBOL.
- qwertyuiop_ 1y ago
  You haven’t seen or heard them because they are abstracted away by APIs, circuit breakers and proxies. Almost ALL banks, credit card companies, travel systems and other high throughput transaction systems run on mainframe that is written in COBOL.
  - zabzonk 1y ago
    I think the issue here is that people working in fintech don't seem to come across these systems much, if at all - if you know one specifically, please tell us.
    - lief79 1y ago
      It's still there at the accounting/backend level. Automated Financial Systems Level 3 and it's replacement Vision are commercial loan systems. LVL3 is pure cobol. It has been recently deprecated but there are many banks who own the code and are still self hosting it, along with it's IBM green screen support. Vision is a java front end in front of an updated cobol backend. When your reputation is based on your reliability and long term code stability, at what point do you risk making the conversion, versus training new developers to work on your system. https://www.linkedin.com/jobs/view/business-analyst-afs-vision-finance-banking-at-jobs-via-dice-4295389587/ https://www.linkedin.com/jobs/view/business-analyst-afs-visi...
      - lo_zamoyski 1y ago
        Analogously, GDSes like SABRE still ran on mainframes until very recently (c. 2023) [0]. SABRE was written in some combination of assembly and some kind of in-house dialect of PL/I, if I recall. [0] https://www.theregister.com/2022/04/11/gds_gets_over_historic_formatting/ https://www.theregister.com/2022/04/11/gds_gets_over_histori...
      - cyberpunk 1y ago
        No, we are not afraid of our own systems. The idea that there is some fabled computer system which everyone is too scared to touch doesn’t exist (I work in payment processing). There are levels of controls way outside these systems which provide these safety nets (e.g settlement / reconciliation controls). If the cobol is still there, it’s not due to risk. If anything, the cobol is a much higher operational risk than replacing it.
    - array_key_first 1y ago
      I worked briefly at a company that wrote applications that interacted with bank mainframes. Think end point bank teller systems and in branch customer/account management. They definitely do exist - every major bank has a mainframe written in (usually) cobol. But it's very abstracted, part of our main product offering WAS abstracting it. On top of our ready to use applications, we offered APIs for higher-level data retrieval and manipulation. Under the hood, that orchestrates mainframe calls. But even then that there could be more level of abstractions. Not every bank used screen-level mainframe access. Some used off the shelf mainframe abstractors like JxChange (yes, there's a market for this). Fintech would be even more abstracted, I imagine. At that point you can only interact with the mainframe a few levels up, but it's still there. Out of sight.
throwaway2037 1y ago
> Working in investment banking, I never saw a single COBOL application What was the back office settlement or wire transfer system written in? There is a good chance that some part of them was written in COBOL. And while Bloomberg terminals are a vendor product, for a bloody long time, many of their screens had some COBOL. Also, lots of quantitative software at i-banks use LINPACK or BLAS, which use FORTRAN.
- zabzonk 1y ago
  Well, I had a very badly specified project to write a library for our back office systems to do Swift payments from our C++ applications, via COM. There was no obvious COBOL involved, on either side, but it has to be said that the whole use case for the library was very murky. And it never worked, due to the lack of spec, not the languages.
umpalumpaaa 1y ago
First hand knowledge: ERGO and MunichRE both have a lot of cobol still doing the core business. You will most likely never run into the system because they just run batch jobs - sometimes configured via a “nice” web UI… you configure your job, submit and the next morning you have your report… that’s why you never actually see COBOL.

In retail banking I'm sure that this could be true. Working in investment banking, I never saw a single COBOL application, or had to have my C++/Java/$MODERNLANGUAGE code interact with one.

davedx 1y ago

Yeah when I worked in investment banking it was VBA and Java everywhere, never saw or heard of COBOL.

cyberpunk 1y ago

Corp bank here, everyone has rumours about COBOL systems but no one I've ever spoke to has seen, interacted or has any other evidence these really exist anymore either.

charlieyu1 1y ago
Me neither. But I asked for a bank statement from my old savings account a few years old and it took two weeks to print out, printed in monospace dot matrix. Or the betting company that I was a customer that suspends betting everyday 6:30am for an hour for daily maintainance. Ironically, they would accept bets for football matches played at the time, but the system was shut down. I suspect both are run on COBOL.
qwertyuiop_ 1y ago
You haven’t seen or heard them because they are abstracted away by APIs, circuit breakers and proxies. Almost ALL banks, credit card companies, travel systems and other high throughput transaction systems run on mainframe that is written in COBOL.
- zabzonk 1y ago
  I think the issue here is that people working in fintech don't seem to come across these systems much, if at all - if you know one specifically, please tell us.
  - lief79 1y ago
    It's still there at the accounting/backend level. Automated Financial Systems Level 3 and it's replacement Vision are commercial loan systems. LVL3 is pure cobol. It has been recently deprecated but there are many banks who own the code and are still self hosting it, along with it's IBM green screen support. Vision is a java front end in front of an updated cobol backend. When your reputation is based on your reliability and long term code stability, at what point do you risk making the conversion, versus training new developers to work on your system. https://www.linkedin.com/jobs/view/business-analyst-afs-vision-finance-banking-at-jobs-via-dice-4295389587/ https://www.linkedin.com/jobs/view/business-analyst-afs-visi...
    - lo_zamoyski 1y ago
      Analogously, GDSes like SABRE still ran on mainframes until very recently (c. 2023) [0]. SABRE was written in some combination of assembly and some kind of in-house dialect of PL/I, if I recall. [0] https://www.theregister.com/2022/04/11/gds_gets_over_historic_formatting/ https://www.theregister.com/2022/04/11/gds_gets_over_histori...
    - cyberpunk 1y ago
      No, we are not afraid of our own systems. The idea that there is some fabled computer system which everyone is too scared to touch doesn’t exist (I work in payment processing). There are levels of controls way outside these systems which provide these safety nets (e.g settlement / reconciliation controls). If the cobol is still there, it’s not due to risk. If anything, the cobol is a much higher operational risk than replacing it.
  - array_key_first 1y ago
    I worked briefly at a company that wrote applications that interacted with bank mainframes. Think end point bank teller systems and in branch customer/account management. They definitely do exist - every major bank has a mainframe written in (usually) cobol. But it's very abstracted, part of our main product offering WAS abstracting it. On top of our ready to use applications, we offered APIs for higher-level data retrieval and manipulation. Under the hood, that orchestrates mainframe calls. But even then that there could be more level of abstractions. Not every bank used screen-level mainframe access. Some used off the shelf mainframe abstractors like JxChange (yes, there's a market for this). Fintech would be even more abstracted, I imagine. At that point you can only interact with the mainframe a few levels up, but it's still there. Out of sight.

throwaway2037 1y ago

> Working in investment banking, I never saw a single COBOL application What was the back office settlement or wire transfer system written in? There is a good chance that some part of them was written in COBOL. And while Bloomberg terminals are a vendor product, for a bloody long time, many of their screens had some COBOL. Also, lots of quantitative software at i-banks use LINPACK or BLAS, which use FORTRAN.

zabzonk 1y ago
Well, I had a very badly specified project to write a library for our back office systems to do Swift payments from our C++ applications, via COM. There was no obvious COBOL involved, on either side, but it has to be said that the whole use case for the library was very murky. And it never worked, due to the lack of spec, not the languages.

umpalumpaaa 1y ago

First hand knowledge: ERGO and MunichRE both have a lot of cobol still doing the core business. You will most likely never run into the system because they just run batch jobs - sometimes configured via a “nice” web UI… you configure your job, submit and the next morning you have your report… that’s why you never actually see COBOL.