In addition to the other answers, I would like to stress that communications from a financial shall be easily verifiable for the user.

Say a customer receives a sms/email:

YOURBANK: Your purchase has been successful. More info https://bit.ly/2VBP5iK

Is this legitimate or not? Even if the to their IT team, that url itself provides no context, requiring them to dig into whatever urls it redirects to. And sometimes even them would not be able to ascertain if it is legitimate or not, e.g. when the bank marketing department decides to launch a campaign at yourbank-campaign.com rather than using their domain (and thus being detected as a phishing to yourbank.com).

Even if https://bit.ly/2VBP5iK now leads to https://yourbank.com/sign-in:

• They wouldn't know who created that shortener. Even if it redirects to a legit page now, the author could later change it to a phishing page. Changing the target url between the legitimate and a phishing page would be a great way to confuse security teams.
• You are training your users that bitly links from your bank are Ok. While any miscreant could create one of those pointing to a phishing to your entity.

And if you buy a new domain (e.g. https://yourba.nk/) to use as a shortener, do place in the website root a text like

This is the official shortener from yourbank.com. All entries here lead to official services by yourbank. See https://yourbank.com/faq#shortener

With the page https://yourbank.com/faq#shortener (at the main site), linked from it confirming the same information.

You will nevertheless end up with users thinking it leads to a phishing page, some blacklist adding a url from https://yourba.nk/, etc. but having a clear domain that can be whitelisted, and the proper information readily available will help a lot.

‎

Note that while I would consider owning the shortener domain yourself a must, actually hosting the domain could be delegated to a third-party like bitly, instead of doing that in the bank infrastructure. That would share only some of the concerns other answers have mentioned (such as the shortener company getting compromised and redirecting [some of] your customers somewhere else). However, while it may be a useful service for another kind of company, for a bank the added cost of hosting a private shortener service would be negligible when compared with that of their normal page which those redirects will be targeting. So I wouldn't host it outside of my infrastructure either.

In addition to the other answers, I would like to stress that communications from a financial shall be easily verifiable for the user.

Say a customer receives an sms/email:

YOURBANK: Your purchase has been successful. More info https://bit.ly/2VBP5iK

Is this legitimate or not? Even to their IT team, that url itself provides no context, requiring them to dig into whatever urls it redirects to. And sometimes, even they would not be able to ascertain if it is legitimate or not, e.g. when the bank marketing department decides to launch a campaign at yourbank-campaign.com rather than using their domain (and thus being detected as a phishing to yourbank.com).

Even if https://bit.ly/2VBP5iK now leads to https://yourbank.com/sign-in:

• They wouldn't know who created that shortener. Even if it redirects to a legit page now, the author could later change it to a phishing page. Changing the target url between the legitimate and a phishing page would be a great way to confuse security teams.
• You are training your users that bitly links from your bank are Ok. While any miscreant could create one of those pointing to a phishing to your entity.

And if you buy a new domain (e.g. https://yourba.nk/) to use as a shortener, do place in the website root a text like

This is the official shortener from yourbank.com. All entries here lead to official services by yourbank. See https://yourbank.com/faq#shortener

With the page https://yourbank.com/faq#shortener (at the main site), linked from it confirming the same information.

You will nevertheless end up with users thinking it leads to a phishing page, some blacklist adding a url from https://yourba.nk/, etc. but having a clear domain that can be whitelisted, and the proper information readily available will help a lot.

‎

Note that while I would consider owning the shortener domain yourself a must, actually hosting the domain could be delegated to a third-party like bitly, instead of doing that in the bank infrastructure. That would share only some of the concerns other answers have mentioned (such as the shortener company getting compromised and redirecting [some of] your customers somewhere else). However, while it may be a useful service for another kind of company, for a bank the added cost of hosting a private shortener service would be negligible when compared with that of their normal page which those redirects will be targeting. So I wouldn't host it outside of my infrastructure either.