4 ms·

Given the crowd on HN I'm surprised there isn't at least one person chiming in that works on these backend bank systems.

by jrcii 11y ago

tolle 11y ago
A wild guess would be that roughly 90% of all systems handling this are written in COBOL running on z/OS or IBM i. And that most of the developers are currently close to 60, spending their free time with their grandchildren and not on Hacker News. I'm not much help either since I work with mortgages, and having it all explained during a lunch break might be a bit much. There are also, depending on company and country, rules and laws about what you can talk about.
- zhte415 11y ago
  There are still a lot of developers for these systems. Updates happen constantly and developers are constantly in need and training-up. For example, credit card legal and security compliance updates happen a lot with really strict deadlines that have to be adhered to, or else the credit card issuer gets into hot water. Some organisations choose to merge old features that differ by country get merged in a central trunk with flagable switches. The code bases are very active. My company (not going to say the name here) employ 500+ mainframe engineers, some working on new projects and codebases because mainframe is the preferred platform. If you or anyone else would like to get in contact regarding COBOL or Mainframe in general, especially getting work done, especially in finance, please find my email in my profile.
  - jrcii 11y ago
    > There are still a lot of developers for these systems. I hear Initech is hiring.
PeterisP 11y ago
I've worked on those systems and there's not much more to say, the hot potato analogy is pretty much a perfect description.
- jrcii 11y ago
  What protocols and software stacks do they use? How are they networked? What are the steps in the verification process? What prevents it from being able to work in real time? Where is this type of information formally recorded? I had a hard time turning it up. For such a critical and prolific infrastructure it's unusually opaque.
  - PeterisP 11y ago
    > What protocols and software stacks do they use? Heterogenous, differs between institutions, differs within institutions, also many/most institutions are a mix of incompatible systems because the business institutions are a merger of mergers with acquisitions of mergers, all while requiring to keep constant operations, full archives of all past deals of all those legacy institutions and compatibility. In some spaces, Java is popular, in some spaces COBOL is used, and many have something from a multitude of different exotic niche platforms. In any case you'd expect to have a mix of systems/platforms, some of them modern, some of them older than you are. You'd have 'common' platforms/stacks e.g. oracle on linux, or mssql on windows, you might encounter something also running on LAMP somewhere, and you might have e.g. a custom platform with integrated DB-like and programming-like functionality running on a particular version of AIX, all of those in a single institution. > How are they networked? All kinds of things. Some use common TLS channels. Some parts of business may even use simple file transfer or public email without expecting the channel to provide any security, but rely on each separate message being securely encrypted and signed. For anyone that you "don't know personally", there's SWIFT that will give you secure though not cheap messaging - if you get a swift message from e.g. FBNINGLA then you can be sure that yes, this actually is an authorised representative of the First Bank of Nigeria. > What are the steps in the verification process? Depends on your pre-existing relationship - if you trust them up to some limit (equivalent to a credit line up to that limit), then you do technical verification that the request is authorised and authentic and that's it. If you don't, you wait until they somehow hand over the 'cover funds' to someplace that you securely control, verify that it is received there (e.g. account statement from that place at the end of their business day), and then proceed further. > What prevents it from being able to work in real time? I believe mainly because multiple independent parts of the process that have no motivation to change, and often have motivation to not change - if you agree to do your part of the things faster and cheaper, it adds cost and decreases fee revenue; and changing things requires cooperation and investment from a majority of players. Up to some part, there may be legal obstacles that prevent some particular ways to be done faster (the liability 'hot potato' issues) but IMHO those would be quickly solved by the industry, lobbyists and involved lawmakers if the motivation was there. > Where is this type of information formally recorded? It's heterogenous, so it's a multitude of similar-and-different things. For any particular payment system you'll have short public descriptions and also available training courses, technical standards, etc though often at a significant fee. It is niche expertise required within that niche, and not particularly PR-useful to publicize in detail, probably entirely the other way around.

Given the crowd on HN I'm surprised there isn't at least one person chiming in that works on these backend bank systems.

by jrcii 11y ago

Given the crowd on HN I'm surprised there isn't at least one person chiming in that works on these backend bank systems.

tolle 11y ago

A wild guess would be that roughly 90% of all systems handling this are written in COBOL running on z/OS or IBM i. And that most of the developers are currently close to 60, spending their free time with their grandchildren and not on Hacker News. I'm not much help either since I work with mortgages, and having it all explained during a lunch break might be a bit much. There are also, depending on company and country, rules and laws about what you can talk about.

zhte415 11y ago
There are still a lot of developers for these systems. Updates happen constantly and developers are constantly in need and training-up. For example, credit card legal and security compliance updates happen a lot with really strict deadlines that have to be adhered to, or else the credit card issuer gets into hot water. Some organisations choose to merge old features that differ by country get merged in a central trunk with flagable switches. The code bases are very active. My company (not going to say the name here) employ 500+ mainframe engineers, some working on new projects and codebases because mainframe is the preferred platform. If you or anyone else would like to get in contact regarding COBOL or Mainframe in general, especially getting work done, especially in finance, please find my email in my profile.
- jrcii 11y ago
  > There are still a lot of developers for these systems. I hear Initech is hiring.

PeterisP 11y ago

I've worked on those systems and there's not much more to say, the hot potato analogy is pretty much a perfect description.

jrcii 11y ago
What protocols and software stacks do they use? How are they networked? What are the steps in the verification process? What prevents it from being able to work in real time? Where is this type of information formally recorded? I had a hard time turning it up. For such a critical and prolific infrastructure it's unusually opaque.
- PeterisP 11y ago
  > What protocols and software stacks do they use? Heterogenous, differs between institutions, differs within institutions, also many/most institutions are a mix of incompatible systems because the business institutions are a merger of mergers with acquisitions of mergers, all while requiring to keep constant operations, full archives of all past deals of all those legacy institutions and compatibility. In some spaces, Java is popular, in some spaces COBOL is used, and many have something from a multitude of different exotic niche platforms. In any case you'd expect to have a mix of systems/platforms, some of them modern, some of them older than you are. You'd have 'common' platforms/stacks e.g. oracle on linux, or mssql on windows, you might encounter something also running on LAMP somewhere, and you might have e.g. a custom platform with integrated DB-like and programming-like functionality running on a particular version of AIX, all of those in a single institution. > How are they networked? All kinds of things. Some use common TLS channels. Some parts of business may even use simple file transfer or public email without expecting the channel to provide any security, but rely on each separate message being securely encrypted and signed. For anyone that you "don't know personally", there's SWIFT that will give you secure though not cheap messaging - if you get a swift message from e.g. FBNINGLA then you can be sure that yes, this actually is an authorised representative of the First Bank of Nigeria. > What are the steps in the verification process? Depends on your pre-existing relationship - if you trust them up to some limit (equivalent to a credit line up to that limit), then you do technical verification that the request is authorised and authentic and that's it. If you don't, you wait until they somehow hand over the 'cover funds' to someplace that you securely control, verify that it is received there (e.g. account statement from that place at the end of their business day), and then proceed further. > What prevents it from being able to work in real time? I believe mainly because multiple independent parts of the process that have no motivation to change, and often have motivation to not change - if you agree to do your part of the things faster and cheaper, it adds cost and decreases fee revenue; and changing things requires cooperation and investment from a majority of players. Up to some part, there may be legal obstacles that prevent some particular ways to be done faster (the liability 'hot potato' issues) but IMHO those would be quickly solved by the industry, lobbyists and involved lawmakers if the motivation was there. > Where is this type of information formally recorded? It's heterogenous, so it's a multitude of similar-and-different things. For any particular payment system you'll have short public descriptions and also available training courses, technical standards, etc though often at a significant fee. It is niche expertise required within that niche, and not particularly PR-useful to publicize in detail, probably entirely the other way around.