This is the sixth article in the series about finding protected attributes in data. We've covered the main four categories (Race, Sex/Gender, Disability, and Age) broadly.
This article dives into a specific attribute: religion. It tends to get less attention than others, but is worth taking seriously; protected in many jurisdictions, can influence algorithmic outcomes in ways that are easy to miss, and can ultimately make our algorithmic systems less accurate.
Religion is typically not a named field in most FS datasets; it’s rarely collected directly.
But there are many proxies. The information can flow, deliberately or not, into other systems: marketing models, risk scoring, fraud detection. Whether that's appropriate depends on the context, but it's worth knowing it's happening.
Here are four such proxies:
Certain names are strongly associated with particular religions. A model trained on names, or on any data that includes names, may be learning religious signals without this being the explicit intention.
Postcodes or zip codes with high concentrations of particular religious communities can act as proxies, much like they can for race or ethnicity.
If we know that a customer holds a faith-based product, like a halal investment account, the institution can infer their religion. The same could hold for a customer that has entered into a Heter Iska agreement, which would imply a particular religion. Customers that opt for faith-based accounts are not necessarily doing it because of their religious beliefs; some consider faith-based products to be ethical choices. These could be meaningful signals of likely religion, but not reliable ones. Either way, using it as an input to unrelated models is an issue, regardless of whether the inference is right.
Charitable giving around religious events, or purchases associated with religious practice, can be visible in transaction data. The same holds for foreign remittances: there are known problems with using such data to infer personal characteristics. For example, this bank flagged a transfer because the name of a specific religion appeared in the payment description.
The practical steps here are similar to those in other articles in this series, but with a few specific additions.
We’ve already discussed postcodes separately.
Names: audit name fields carefully. They're often fairly reliable proxies for religion, and are naturally present in FS datasets. If names are used as inputs, or if models were trained on data that included names, that's worth examining.
Transaction patterns: review remittance and international transfer data in credit and fraud models. Ask whether these patterns are being used, and if so, whether their use is justified, and tested for fairness.
Faith-based products: check whether any faith-based product data flows into models that weren't designed to use it. If a customer's product choice reveals their religion, check where this information goes.
In each case, the goal is the same: confirm that proxies for religion are not influencing decisions.
Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.