As you consider implementing a treasury management system, you may experience relief at the thought of moving away from manual processes, anticipation of greater efficiencies and more productivity in your team, and also dread—dread at the thought of the implementation. If you haven’t implemented a TMS before—get ready. It’s about to get real.

When creating your project roadmap and building your project plan for the implementation, several key elements which typically lead to scope creep come to mind—resources (both internal and external), concurrent treasury projects, IT availability, and getting ROI in the time you’ve promised to secure budget. Another outlier is lurking out there, waiting to wreak havoc on your project roadmap—bank onboarding.

Considering Banks in Your Implementation Plan

When you talk to TMS providers during sales meetings, they’ll tell you that the banks “come online” in one or two days. Even when you’re signing the final agreement, you’ll see minimal resources dedicated to bank onboarding. That’s because bank onboarding is double-sided—the TMS provider, in most cases, will provide significantly less than one-third of the manpower involved in bringing up a bank for information reporting and less than one-fifth for payments. The other half falls on—you guessed it—YOU! You get to initiate global project teams with the banks for all your main global banks, fill out loads of documents, trace down signatories in all corners of the earth—and even though you have that POA in place which should make global signers possible…it’s not going to be accepted in some countries.

So in this article, we’ll explore some ways to make bank onboarding a friendlier process—so you know what you’re up against, can avoid some common pitfalls, and can set a realistic timeline for your project.

There are several logical ways to approach onboarding your banks to your new TMS. After you’ve considered those outlined below as well as others, you can determine what works for your team and structure and incorporate that approach into your project roadmap.

• Highest Percentage of Accounts / Balances. You might choose to select the banks with which you hold your highest balances across the globe and move forward with those banks first.
• Regional. Alternatively, you might have a regional approach to your entire TMS project—perhaps you are rolling out the TMS to North America or Europe first and plan to then add other regions later, after the pilot region is complete. In that case, you’d logically onboard the corresponding regional banks for the pilot phase.
• SWIFT Capability. If you are connecting to your banks via SWIFT, you might target all SWIFT capable banks first and move on to others in a later phase.
• Big Bang. You might be focused on quick results and go for a Big Bang approach—contacting all banks simultaneously and bringing them up as quickly as they respond.
• Payments. In some cases, you might think through which banks you’ll plan to do high urgency, high value payments to out of the TMS and move forward with those key players first.
• Information Reporting. In other instances, you might not be ready to begin payment testing early in the game and plan to implement the payments module further along in the process. In this case, you’d bring up your banks for information reporting (daily statements) first and then approach payments later.

Setting Realistic Timelines for Bank Onboarding

You’re about to kick-off your TMS project, and you’re trudging through the old Microsoft Project plan, agreeing to dates, assigning resources, and blindly hoping you can meet all the deadlines in there. Does this seem like a reasonable timeframe? Sure! Before you find yourself reporting three or four weeks behind on your project plan, save yourself some frustration and read through the following items to consider when approaching one particular suspect in scope creep gang—bank onboarding.

First, it’s crucial to set management expectations. Senior staff like to see steady progress and will push back when progress appears to have plateaued. Prepare senior staff up front for the time each phase may take. Ensuring expectations are aligned early on can help when you’ve had some big wins, followed by a lag as you work to bring your straggling banks onboard.

Set yourself up to be able to say, “We expected to see progress slow during this time, and we remain on track to hit our go live date.”

Don’t be overly ambitious or optimistic when it comes to bank onboarding. Unless you have only a handful banks and you work closely with all of them on a consistent basis (or you’re working with an experienced partner who can speed things up for you), expect things to take a while. Build your TMS timeline so that you aren’t dependent on a large number of banks being live with information reporting or payments before you can go live with your cash and payments modules.

As you consider each bank, here are a few elements to consider with each:

1. Complexity of Multi-Regional Banks. While multi-regional banks have the most established procedures for connectivity projects, they also tend to require the most documentation and that you move through a highly bureaucratic process, involving global and regional implementation managers and months of weekly phone calls. Cushion your multi-regional banks with some extra time in the project plan. Also, be sure to ask about any countries which are common laggards at the bank with their local teams.
2. Complexities of Payment Testing Across Regions. Despite the fact that payment formats have come along nicely in the past decade and global standards have been rolled out, country-by-country specifications still exist. Your TMS may need to do some customization for a specific bank/country format in order to accommodate.
3. AsiaPac. While some banks in AsiaPac will begin sending statements quickly, many will not. Even when you have an in-region resource to help you, there are often delays. Payment testing in AsiaPac can be particularly tricky, sorting through the various payment network, currency, and format requirements.
4. Boots on the Ground / Local Resources. For all regions of the world, you’ll find that your local treasury teams can help you make the quickest progress. The banks are familiar with these contacts and will be more likely to respond quickly and feel comfortable with their usual contacts.
5. Buy in from Regional Teams. Because of this, it’s especially important to take plenty of time up front explaining the TMS project, how it will impact the regional team during the implementation, and how it will change their usual processes.
6. Language Barriers and Time Zones. Many banks require that documentation be completed in a local language. You can request a translated version for reference, but they may not be able to provide—and they’ll likely require that you sign the local document for legal reasons. Time zones can also be a factor with both communication (scheduling calls, lag time in payment testing results) and payment testing requirements. When you’re performing payment testing, you may be working with a US based TMS resource who is sending out the first round of payment tests on your behalf—and you may be working with a bank that requires you only allows you send payment tests during a certain timeframe when your US resource is asleep! Negotiating these speed bumps takes time.
7. What if a Bank Isn’t SWIFT Connected? For your banks which aren’t connected to SWIFT, you’ll need to figure out a connectivity plan. Non-SWIFT banks usually end up on an extended timeline.
8. Your Team’s Timeline and Deadlines. As you build out your timeline, also consider month/quarter/year end close, other projects, vacations and holidays (across regions), internal staffing changes, and external project resource changes, etc.
9. Blackout Periods at Banks. Find out any blackout periods from each bank or go-live windows before you commit to a timeline.
10. SWIFT Mode. For your SWIFT banks, you’ll want to find out for payment testing if they are operating in future or current mode before you being sending tests.

Implementation Checklist for Bank Onboarding

As you mentally prepare yourself for the marathon of connecting your banks to your TMS, make sure you are ready by reviewing this handy checklist. These questions will help you think through your approach so you aren’t surprised by unexpected questions along the way.

• Connecting Globally. How are you going to connect globally? There are several ways to connect globally—through a global bank, a treasury aggregator, directly to each bank, or directly to SWIFT. Have you considered and explored the connectivity capabilities of each bank on your list?
• Payment Instructions. To which banks are you sending payment instructions? An implementation for payment instructions is much more complex and time consuming than setting up information reporting.
• What formats are you going to use? For both information reporting and payments, format choices must be considered. Will you go with the flexible and forward-thinking formats or the tried and true?
• For banks from which you wish to receive statements, are you going to request prior day reporting and current day reporting? How many times a day do you need current day reporting?
• Central Contact. Who will be in charge of contacting all of your banks? (i.e., corporate team or local teams)
• Bank Portals. Will you continue to use the individual banking portals, or will you discontinue use? Some people centralize and discontinue use of banking portals while others hold onto them as a backup or for tax payments.
• Bank Fees. What is your budget for individual bank fees for the project? Incorporate bank fees into your project budget early so you aren’t surprised later on.
• Errors and Confirmations. Will you require error/confirmation messages? Can your TMS accept these?
• Data Requirements Are there any data requirements for other systems involved (i.e., reconciliation system, ERP)? If you are planning to use the daily statements for any system other than the TMS, the technical requirements of that system must be considered as well.
• As you consider your relationship standings at your banks, document whether the relationship is maintained by the sub or if it is managed by the corporate team.
• Accuracy of Account Records. Likely, a list is floating around with most of your bank accounts on it. Who maintains this list? Is it accurate? Do you have an up to date list of authorized signers for each account?

Each of these elements must be considered for a successful bank onboarding project. As you create your technology stack, be sure to consider flexibility and change. Build something that can last beyond you and can survive one of your technology providers being acquired. We’re always here to discuss any of these elements as you get started.

Considering Reporting Formats in Your TMS Choice

As you consider setting up bank reporting into your TMS, more choices must be made. Why, you may ask, should it matter to you in what format you receive your information reporting as long as your balances are there when you need them for your daily cash position? In actuality, there are many factors that should play into your choice. Let’s take a look at the most common syntaxes provided through SWIFT—MT and MX (ISO 20022).

The MT (message type) syntax, which is the most common, was developed in the 1970s when SWIFT was first formed. More messages were added over the years to form the complete group which we use today. Many corporates choose to implement MT messages because they are familiar and accepted by many banks. When sent through SWIFT’s FIN network, MT messages are validated by SWIFT, which proves to be a huge advantage for these messages. SWIFT creates the ACK and NCK which let you know if your message was filled out correctly and will be readable by your counterparty. No other form of messaging or syntax provides this level of validation within the network.

While MT messages are still being used by many banks, they are no longer being updated. Furthermore, they are becoming outdated with the introduction of ISO 20022 syntax and messages. All new messages are being created in the more flexible format of ISO 20022. New messages, such as payment initiation in the SEPA format, are in the XML format. Why does flexibility matter when it comes to messages? If there is a mistake in an MT message, treasury technology systems will not be able to integrate the message. With an XML/ISO 20022 message, the messages will often still be able to integrate and there will be an error in the specific field. This is helpful because valuable information is still available.

During this period of coexistence as banks are using MT and XML messages, SWIFT provides the Standards Translation Rules. This allows a corporate to send an XML message to their bank, if their bank accepts XML. Then, if their counterparty must receive the message in MT format, the bank can use these standards to map exactly, field for field, what the counterparty needs to see. More and more banks are adding XML capabilities every day. SWIFT also provides a guide (https://www.swift.com/topic/34641/certification/banks#topic-tabs-menu – put in this link) on their website to see which message types individual banks offer called the Bank Readiness Portal.

When approaching a bank, it is important to reference the Bank Readiness Portal as many bank employees may be unfamiliar with all message types and could misunderstand their capabilities—another tool in your kit as you move toward a successful and on time TMS implementation!

Bank Account Management: Easing the Burden on You and Your Banks

In this series, we’ve been looking at considering bank onboarding in your TMS implementation plan. We’ll now look at layering in bank account management (BAM) and bank fee analysis as simultaneous or consecutive projects, beginning with bank account management.

Setting up a BAM module and TMS simultaneously allows you to minimize the number of times you must reach out to each bank. You may even be able to work with the same contact or implementation team for both the bank onboarding and bank fee analysis projects. Furthermore, as many TMS solutions offer a BAM module, you may be able to adopt BAM functionality directly through your treasury software provider, which further streamlines and simplifies the project.

The first step in any BAM project will be to determine the scope. For each account that you have, consider the following questions with your team:

• Is the account used?
• Can you close the account?
• Can you move the account to a central banking partner in the region to simplify your structure?

Once you’ve determined the scope of your project, you’ll begin onboarding your banks for connectivity, payments, and BAM and will effectively knock out documentation for all three phases simultaneously. Additionally, as you add banks for connectivity and payments, you’ll already be compiling information regarding the authorized signers on your accounts. Some will almost certainly require updates. You’ll be gathering your copies of passports, driver’s licenses, articles of incorporation, etc. for connectivity and payments contracts—so why not file those documents centrally and have them on hand for easy access and updates later?

Banks are requiring more and more forms of identification and are applying more stringent validation proofs to their processes due to the ever-increasing know-your-customer (KYC) regulations. Being ahead of the game on BAM will only save you time down the road.

Additionally, this will put you in a good position from a security perspective, as it will enable you to quickly change out a signer as necessary if an employee leaves the company. Very few companies act to completely remove ex-employees as signatories on bank accounts in a timely manner.

Positioning yourself for time savings, efficiencies, and controls for the present and the future is most certainly a win for your treasury department.

Bank Fee Analysis: An Often Overlooked Cost-Savings Opportunity

You’ve carefully selected each of your banking partners. You maintain each key relationship. You’re looking at connecting to your banks via SWIFT for connectivity and payments. How can you gain further efficiencies and save your company money in the process?

Rolling out bank fee analysis along with bank onboarding and bank account management will provide these additional benefits. Since you’ll already be in contact with the banks for connectivity and payments, it will minimize the number of times you must reach out to the bank. You may even be able to work with the same team or contact.

Negotiating bank fees as you set up your SWIFT services will save you money over time. Additionally, you can address other fees you have in place at the bank, ensuring that you are:

• Being charged the contracted rates
• Requesting lower rates where applicable

While you never want to jeopardize your key banking relationships by pushing beyond the line with fee cuts, you also want to make sure the fees you are being charged are fair and logical.

Another thing to keep in mind is the continuous monitoring of bank fees. Rather than looking back every few years or spot checking your fees, corporates often find that outsourcing their bank fee analysis to an external group saves them hundreds of thousands of dollars over the course of a few years. These savings significantly outweigh the cost of the monitoring service and ensures that you are only paying for what you agreed to.

Another cost-savings strategy to consider as you set up your SWIFT reporting is to make sure you are only turning on necessary services. Current day reporting is excellent for high volume, operational accounts—but it isn’t necessary for the majority of corporate accounts. Since current day reports are typically sent multiple times throughout the day, the fees around them rack up quickly. You often receive a charge from the bank for each message—and your current day reports will be the heaviest offenders for pushing you over the edge on your SWIFT bands. In many cases, if you have a corporate BIC, you’ll be charged in “bands” which are pricing tiers. Once you exceed a specified message volume, you move to the next “band” which pushes your price point up in an incremental chunk. By only setting up current day reporting on the accounts you need, you’ll ensure that you are staying in the appropriate SWIFT bands and are only paying for the visibility that you need.

When we perform bank fee analysis for our clients, we often find years of unnecessary spending—where countless dollars could have been saved on an annual basis. Save yourself time and expense by:

• Connecting your banks via SWIFT for information reporting and payments
• Setting up bank fee management during the process
• Rolling out bank fee analysis services at the same time

What is Sanction Filtering, and Why Is It Important to Your TMS Implementation Plan?

Compliance in the modern business environment has become an incredibly complicated area of operations for organizations but must be considered in the selection and implementation of a TMS. Sanctions screening involves checking each financial message against sanctions lists to ensure that messages are not sent to known terrorist or organized crime groups. As you onboard your banks, you must consider how you will go about implementing ongoing sanctions screening checks to ensure your organization remains in compliance.

One of the most frustrating components of sanctions screening is that the lists of sanctioned parties is lengthy and constantly changing. To make matters worse, the fines associated with failing to comply with sanctions compliance is on the rise. In fact, penalties administered by the Office of Foreign Assets & Control (OFAC) for sanctions related violations nearly tripled between 2008-2011 and 2012-2015. Civil penalties totaling nearly $600 million were assessed by OFAC in 2015 for sanctions violations, with fines ranging anywhere from $38,000 to $300,000,000.*

Despite the heavy penalties associated with non-compliance, however, corporates have been slow in their adoption of sanctions screening tools. According to a recent survey, 35% of respondents indicated that they do not screen for sanctioned parties on outgoing or incoming messages, with 12% inadvertently making payments to or receiving payments from a sanctioned party in 2016.** This is troubling, the penalties being assessed against organizations that fail to comply.

This reluctance to implement sanctions screening software may be on account that it has generally been banks that have been held accountable for the screening of financial messages in the past. And with the list of sanctioned parties so vast and constantly under revision, many companies are under the impression that the implementation of sanctions screening software is too burdensome a project to undertake.

However, through either your TMS or your treasury aggregator, the sanctions filtering process can be made much easier. All messages sent and received by a client can be automatically screened to ensure compliance of all relevant regulations with little-to-no manual intervention. By implementing sanctions screening through your TMS or treasury aggregator, a payment could be stopped in its tracks prior to being sent to the bank, at which time it becomes a reportable event, thus saving your organization hundreds, thousands, or even millions of dollars in penalties.

Considering sanctions screening as a part of your implementation sets your team and organization up for success in future years. You’ll avoid headache, and can rest assured knowing you’ve implemented a well-rounded solution.

Footnotes:
* Annual penalties assessed statistics provided by www.treasury.gov.
** Strategic Treasurer & Bottomline Technologies. “Treasury Fraud & Controls.” Survey. StrategicTreasurer.com. 2016.

Annie Reid

Director, Connectivity & Onboarding
Annie Reid is a Treasury Analyst working with Strategic Treasurer’s clients. A connectivity and bank onboarding specialist, she is the head of Strategic Treasurer’s bank onboarding team. When Strategic Treasurer’s clients make a major change that impacts their banking relationships, such as selecting new technology or a new treasury aggregator relationship, her team handles all of the ensuing communication and connectivity changes. This encompasses: information reporting and payments; making decisions regarding file formats and communication methodology; and handling all bank and technology firm calls and documentation management. For payment testing, her team creates a custom test case inventory and oversees and tracks all UAT and production testing. Annie works closely with SWIFT and is a SWIFT Certified Trainer currently delivering training to corporates and bankers on SWIFT for Corporates and Alliance Lite 2.