Not fintech, but I dev and maintain some systems with business-logic-in-DB. We use Oracle, the language is PL/SQL. You get one level of namespacing, and functi

Not fintech, but I dev and maintain some systems with business-logic-in-DB. We use Oracle, the language is PL/SQL. You get one level of namespacing, and function names have to be less than 32 characters, so abbreviated names are common. This can be unwieldy, but alleviated by good comments and docs. You want to code each function to do one thing: have a well-defined input, and a well-defined output. Living inside the database gives us transaction support for free -- atomic operations that either succeed or rollback. The application running inside the DB defines the external interface with its functions (the same way a web service or a library would), and keeps the raw tables as an implementation detail. If we moved more functions out of the app into a higher layer (ie. Java/Python/etc), we'd actually have more functions overall, as you'd either have to have a bridge method that calls the equivalent function inside the DB, or rely on an ORM and invent some instrumentation to deal with concurrency requirements [1] At the end of the day, a modern RDBMS allows you to implement applications that present a well-defined interface to the outside world, with the internal implementation remaining a private 'black box'. [1] https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html/transactions.html#transactions-optimistic https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/htm...