Why Large Financial Institutions Prefer SAS While Internet Companies Favor Python: A Comparative Analysis

Introduction

When discussing open‑source versus closed‑source software we usually refer to the availability of the source code, but for data‑analysis applications another dimension matters: whether the language used to write the application is itself open‑source.

This creates several combinations, such as open‑source software written in an open‑source language or closed‑source software written in a closed‑source language.

Two typical examples are compared: the open‑source language Python used in open‑source software, and the closed‑source language SAS used in closed‑source software.

Why Do Large Financial Institutions Use SAS More Than Python?

1. Historical Legacy

Python was created in 1991 but only became widely adopted for commercial production in the last five years.

Before that, many large financial institutions already had extensive codebases written in SAS.

Why not refactor old SAS code into Python?

Experienced developers often advise that if the existing code works well, it should not be rewritten.

2. Talent Pool

There are far fewer professionals proficient in SAS than in Python because SAS is mainly used for data‑analysis and requires strong statistical knowledge, whereas Python’s broader applicability attracts a larger talent pool.

A 2016 study of U.S. industry preferences (still relevant) shows that internet companies expanding rapidly cannot limit themselves to the small SAS talent pool.

3. Stability and Precision Requirements

Financial institutions use SAS for risk‑control, credit scoring, investment decisions, and quantitative models where errors can cause substantial monetary loss.

Internet companies mainly use Python for recommendation engines and product operations, where mistakes are less catastrophic.

Consequently, financial firms demand higher stability and computational precision.

Python libraries such as pandas still have many open issues (over 3,000), and community response times cannot match the 24/7 support offered by commercial vendors.

Undetected numerical discrepancies or potential malicious code in open‑source packages are especially concerning for risk‑averse financial institutions.

4. Credit Backing

Commercial vendors provide stronger credit backing than open‑source communities, which is crucial for heavily regulated financial sectors.

If an open‑source tool fails and causes loss, the institution must bear the responsibility alone.

5. Cost

SAS offers stability, precision, and credit backing, but at a high license and maintenance cost, which can be prohibitive for smaller financial firms.

Python’s costs are more implicit (potential downtime, hidden bugs), but as development teams mature, these risks diminish.

Is There a Middle‑Ground Solution?

1. Financial Institution‑Centric Hybrid

Many firms model in Python but deploy in SAS, using scripts to translate Python code to SAS, thereby leveraging Python talent while retaining SAS’s stability and regulatory acceptance.

This approach still incurs dual‑license costs and requires staff proficient in both languages.

2. SAS’s Own Hybrid Strategy

SAS Viya now supports open‑source languages, allowing organizations to use Python while benefiting from SAS’s stable runtime and support.

3. Addressing Cost and Legacy Issues

A commercial product called WPS (different from the office suite) can execute SAS code and also run Python, offering a lower‑cost alternative for maintaining legacy SAS models without full license renewal.

WPS was recently acquired by Altair, which aims to help companies transition from closed‑source to mixed language architectures while reducing costs.

References

[1] r‑vs‑python‑vs‑sas: https://medium.com/@akeriasolutions/r-vs-python-vs-sas-8224d2a426ae

[2] SAS R Python analytics pros prefer: https://www.kdnuggets.com/2016/07/burtchworks-sas-r-python-analytics-pros-prefer.html