PHP What programming language is used to store Bank Acct's/money?

AI Thread Summary
User account data on websites is typically stored on servers using various programming languages like PHP or Ruby, while banking information is often managed differently due to security and regulatory requirements. Banking systems generally rely on older technologies, with COBOL and DB2 on MVS being common for sensitive data storage. Banking data is stored in relational database management systems (RDBMS) with added layers of encryption and strict access controls. Java, C++, and .NET are also prevalent in banking software, but legacy systems often remain in COBOL due to the complexity and cost of migration. Decimal-based math is crucial for financial calculations, and mainframes continue to be favored for their security and performance. The mix of legacy code, including assembly language, complicates modernization efforts, as extensive testing is required to ensure new implementations are error-free. Overall, while modern languages exist, many banking systems still heavily utilize older technologies due to their established reliability and the challenges of transitioning to new systems.
Jarfi
Messages
384
Reaction score
12
is it PHP-MySQL?

In websites accounts of users tend to be stored in servers, and on these servers they store the data in some syntax and use PHP, RUBY or something else to add/change the information.

Is it the same in bank accounts? In what format is banking information stored?
 
Technology news on Phys.org
Chances are high that it is COBOL on a DB2 under MVS.
 
Jarfi said:
is it PHP-MySQL?

In websites accounts of users tend to be stored in servers, and on these servers they store the data in some syntax and use PHP, RUBY or something else to add/change the information.

Is it the same in bank accounts? In what format is banking information stored?
It depends on which core application they use. Sensitive data is usually stored in RDBMS tables like any other data, except it is protected using application-level encryption, column-level encryption, or full database encryption; proper database access controls are still necessary to limit the data users/roles have access to.
 
  • Like
Likes Jarfi
There are older programming languages / technologies (to some degree) in the banking system as fresh_42 points out. There has also been migration regarding software platforms - especially during the last decade. Banking systems (regarding the whole platform) consist of various parts. Software platforms / technologies for banking are chosen in a rather conservative way or in other words must be well tested and somewhat mature regarding security, stability and technical support. Java is one of the widely used technologies, C++ and .NET platform (with C# the dominant language) are as well. In database technologies / RDMSs Oracle is a major player worldwide but there are other technologies used as well.
 
  • Like
Likes Jarfi
One of the issues with banking systems, is the common practice of performing all calculations involving money using decimal based math (usually fixed point), which is required by banking laws in some countries. COBOL includes decimal based variables (packed or unpacked decimal (using BCD - Binary Coded Decimal)).
 
I've even seen old assembler code. I don't think that C++ or something makes a lot of sense on a mainframe. And mainframes still cover security, grading and performance best. I've heard of migration attempts that went wrong. One reason is, that you cannot migrate what you don't understand. And since the early 80's there's really a lot of code been written. And hopefully my bank does not use PHP and MySql. What a horrific imagination! That would be worse than abacuses.
 
fresh_42 said:
I've even seen old assembler code.
In the case of IBM mainframes, some of their database access methods are/were implemented as assembly language macros, so applications ended up with a mix of COBOL and assembly. Once assembly was part of the mix, additional code was written in assembly for performance reasons, and these days, assembly remains somewhat due to these legacy issues. It's hard to justify porting large libraries of working legacy code to newer languages due to the time it would take to verify the new code was error free.
 
In languages such as C#, the programmer can take advantage of object abstraction. A persons bank information is stored in a RDMS database which is a relational layer for account processing and data security security layer. The choice of the programming language is then independent of the information being processed.
 
As others have pointed out the code is likely to be legacy stuff in COBOL as it is really expensive to port these large business applications. Our local Telecom company had a system consisting of 10 million lines of COBOL. Our nationwide banking system has been in operation since 1972 so probably consists of a lot of COBOL. Also companies that make big mainframe computers like IBM try to make them backward compatible with old applications to slow the need for migration.

Cheers
 
  • Like
Likes jim mcnamara
Back
Top