Banking sites are hardly monolithic. A bank usually relies on dozens or even hundreds of third party systems in their overall solution. You might have a banking host provided by one vendor, a credit card solution from two or three more vendors, a signon solution provided by yet another, payments by another. The work to put together these sites is enormous.
It is not at all uncommon for banking sites to involve third parties on the front end as well. This could range from third party libraries just to render a calendar control to systems that provide user behavior analytics and risk decisions. Many of these vendors offer script and content via content delivery networks (CDNs), meaning that the files might come from a third party domain.
Is this dangerous? It can be. If the third party resources are not verified via Subresource integrity, they could be modified by hackers (via Man-in-the-middle) or even the third party itself (e.g. malicious employee). So any online banking implementation will either host the content themselves (i.e. copy and paste the third party files onto their own web server) or in some cases deliver the content with a cryptographic hash, notated via the
integrity attribute of the
script node or
link node that references the external file. In yet other cases, they will link to the CDN but provide fallback behavior to a local file (see this StackOverflow question) in case the SRI check fails.
Should I be worried of tracking domains on a banking website?
It is important to note that in the EU, the cost of fraudulent transactions is borne by the institution. Online banking security, therefore, has the primary mission of protecting the bank, not you.
Whatever architecture OP came up with, you can be certain that it passed several layers of risk assessment and review and the decision to use a CDN to serve some content was not made lightly. Chances are they have implemented it properly and are using some means of SRI. You can still worry, but the worry should be minimal.