Maria Long: The big decision as to whether you want to do things in-house or to outsource depends on the type of manager that you are.
For a large manager with a large in-house development team and proprietary software etc. it probably makes more sense to do the innovation internally.
You can link it up with your systems better and have more control over it, as you are likely to have more complex operations and FX risk needs.
However, if you are a smaller firm and are using vendor solutions for other software, then it makes more sense to outsource so you can have the tech support that you may not have internally.
"The big decision as to whether you want to do things in-house
or to outsource depends on the type of manager that you are."
There is also a middle ground that I have seen with both larger and smaller managers.
With the rise of the Fintech industry and the various smaller providers, there is the option to get in early with a new vendor.
This of course takes more time and effort, as you have to find the vendor first and work through beta testing etc., but you do get the benefit of being able to help customise it and make it work for your business, as well as the benefit of an external technology team.
It means that you may not need the technological expertise in-house because you can work alongside the third-party provider and can tailor the design for your business needs.
Maria: In terms of FX and FX hedging, the benefits of centralisation are having everything in one place and having a holistic view of your full exposures.
If you are then using this data to trade the FX hedges, you potentially have the ability to aggregate these trades, which means fewer trades and therefore lower trading costs.
"The benefits of centralisation are having everything in one place
and having a holistic view of your full exposures."
Also, if you have a centralised team looking over this, the knowledge that they might gain viewing the FX as a whole would be beneficial as well.
That being said, particularly with larger firms, the more you centralise something you can lose the more product specific knowledge that may enable someone to spot when something doesn’t look right, even though all the calculations that have been set within the automation look correct.
Maria: If you are going to automate this process then it needs to be treated in the same way as if a person was manually completing that process.
You should have a person who is responsible for this process. This should be someone on the business side, not just technologists, so that they understand what the process is trying to achieve, as opposed to how it works.
If you wouldn’t let one person perform all of these tasks without someone approving or reviewing it, then you shouldn’t let a process do all of these tasks without oversight.
"I don’t like the phrase zero-touch and don’t feel that I would
ever be comfortable with a truly-zero touch process."
The governance aspect comes into play in terms of what controls and checks you are going to put into place. Again, it comes down to the workforce’s skills.
People won’t be building these calculations from scratch anymore, so how do they learn what the system is trying to achieve?
In the early stages of automation this is OK because you have people who did the process manually before and who understand the process, but the question is how do you train the next generation of people who are going to govern these processes if they have never had to carry them out manually?
Maria: I don’t like the phrase zero-touch and don’t feel that I would ever be comfortable with a truly-zero touch process.
Low touch is different and of course, with the volume of the transactions that some firms carry out you cannot realistically look at every transaction.
However, there should be exceptions in place so that most trades can go through, but if they breach a sensible tolerance then they are reviewed by someone.
If you wouldn’t let someone with zero experience do the job just following a set of procedures with no oversight, then you shouldn’t let an automated process do that.
The types of questions that I am asking, particularly on the operational side for automated processes are changing, as I want to know more about the development and release controls and who is involved.
"If you wouldn’t let someone do the job following a set of
procedures, then you shouldn’t let an automated process do that."
For example, is the business involved, as well as the technology departments? Who is putting these controls in place? And how long parallel testing was completed to ensure that it was giving the right answers?
Although, this last question is specific to where there was a manual process in place, which has now been converted to an automated process.
Most importantly, I want the people to be able to demonstrate that they have the necessary knowledge of what the automated process is doing and what the outcome should be. This is the only way that I am going to get comfortable.
If I am speaking to someone who can’t tell me what the process they are responsible for is doing, then it is a black box and will be something that I would struggle to get comfortable with.
