It takes the will and discipline to use it, but what Clojure Spec (and other schemata libs) offer is, in a lot of ways, more powerful and flexible than traditional type systems. A spec can be thought of more as a contract with the data, one with enough detail that it can be used to auto-generate conformant example data even. If, for instance, you have a function, that needs to work on either, integers, or numeric strings, and textual fractions like '1/5'. Enforcing this constraint on input, and getting informative exceptions on bad data is easy with a spec, and the function code does not need to contain all of the noise to validate or coerce data. Sure, you don't see the problem at compile time, but if you can auto-generate test data, the tests that you should already have become easier to write.

this is perhaps controversial but i actually think datomic is so powerful, it's worth using clojure for. in other words, the database is driving the choice of programming language.

the idea of viewing a database as an immutable state of the world at a given instant t0, and time becoming a parameter on that state of the world (in order to show changes as time goes forwards [or backwards!]), is extremely, extremely attractive for things like finance, whose first class citizens are among others:

- capability for audits e.g. show me the history of transactions from any particular account. since datomic is basically a collection of immutable facts over time, this is "free"

- distributed computing - datomic runs nicely across your own internal compute (often needed for financial stuff)

- transactions are no longer strings, but are actual data structures - this makes the gnarly steps of things like transferring assets across instruments a lot easier (i'd imagine). think about how you'd implement a shopping cart with transactions in postgres vs. how you'd do it with access to raw data structures

Moreover, transactions are reified and can have arbitrary metadata, so you can query the transaction log itself (for example, "show me all transactions issued by person X").

I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).

Standard Chartered, Mercury, Tsuru Capital (Haskell), Jane Street (OCaml) don't seem to have a problem with using a statically typed language in the financial space.

maybe they do have a problem if their net worth is so low in comparison :D

Unlikely. At least not for domain modeling.

Especially in that industry where your domain is changing all the time, where regulations are changing all the time, where the ability to reason about your domain at different points in time is essential.

Having more flexible types like maps is one of the building blocks to avoid complexity (there are more, more important ones) It sounds counter-intuitive, but it certainly is working out for companies embracing clojure.

I wouldn't think that strong types are an advantage. They may be in classic software with long compile times and complex builds. However, the current landscape for financial institution doesn't require that. Immutability and functional paradigms seem to be much more in line with the needs of the business.