Mike Salsbury is head of product development at Caplin, the London-based software vendor which designs trading technology for banks and other financial firms. Caplin specialises in web-based trading platforms for cross-asset trading, though the firm has carved an especially strong position in electronic FX markets. QA Financial met Salsbury at Caplin’s London headquarters.
Q: Mike, what are the major trends driving Caplin’s business? What are your clients asking for?
Mike Salsbury, Caplin
I think the two major things we see shaping our clients’ businesses as far as technology is concerned are regulatory compliance and digitisation. And in terms of actual spend, banks have to deal with regulation first. there are so many new features of technology they want, but they have to address regulation first and to a great extent that means transparency in price construction. They need to be transparent – to show accurately where the market is trading – to their customers, and also to the auditors. One challenge is that the auditors and the regulators are themselves still trying to understand what works and what doesn’t. And, as we are seeing with the uncertain deadline for MiFID II, the schedule of regulation is changing. So it is challenging to have a detailed plan over say three years with a wonderfully organised waterfall finish because the regulators might simply change their mind and ask for something different.
Q: Does Agile development help you to respond to those changes?
Yes, that is a big reason why we work in an Agile and intuitive way, so that when the regulators do change their minds and want something different, we can adapt to that. Agile for us means that while we have a plan, it is adaptable, and we do that in two weekly increments, or sprints. We have a big wall with a big story map of those sprints which outlines what we’re going to do over weeks and months to deliver the features required from a project. If the underlying schedule changes for extraneous reasons, we can just change the story map. We can see what effect that has on the scheduling of our two week sprints, and re-plan accordingly. We can mark changes directly on the wall for everyone to see, and we also use Jira software to track development by putting the story maps onto our screens. That ’s especially useful because we have developers working in Ireland and Australia as well as in the UK. But for the team here in London it’s still very useful to be able to stand in front of a story map, or sprint board together and talk about what we did yesterday, what we’re going to do tomorrow, and what blockers we have. That’s what the Agile scrum style means for us. A key to digitisation is being able to integrate with third party messaging systems, such as Reuters RET [Reuters Electronic Trading — the Thomson Reuters platform for FX and money market trading] being the major one for our products. Again, being agile and flexible allows us to integrate with other standards, but if you can do RET and FIX [the Financial Information eXchange Protocol — a messaging system for securities markets], you can do pretty much anything. We have a layer of abstraction in which we are treating all things in a similar way. I use to work with online gambling platforms and it’s a similar process: to integrate, you need to do three things. You need to be able to access account information, place a bet, and settle a bet. Unless they use the same software, all gambling platforms while they do it slightly differently, they all need to do those three things. You could argue that it’s similar in finance. I think increasingly banks want to buy not build. And what they want to buy is a common solution. But while effectively everyone is doing similar things at the platform level, there are lots of other things you could do in addition; such as monitoring market news in different ways. So it become far more complex, especially because of the need to integrate with third parties, which is why you need that layer of abstraction in which to map things out.
Q: Aside from those necessary integrations, what else does digitisation mean for your customers in terms of innovation?
Innovation really boils down to using technology efficiently. What are there opportunities to bring things together and remove screens we don’t need? Do we need so many people on the phone if we can trade automatically instead? And analysing and then visualising data within the system is very important; for example analysing the history of previous interactions between the salesperson and the client. You might see that this client keeps going to the screen, they are repeatedly almost trading on something, but they don’t. Or it might be an opportunity to embed a currency derivative in a structured product that might be of interest to the customer. If you’re a sales trader and you can see that information, then you can give them a call.
Q: Does that sort of visualisation run as a continuous stream of messages to the sales trader?
There is a trade-off between the accuracy of algorithms you might use to do that and the efficiency of the system from a user’s point of view. A less efficient algorithm might be better if it works more quickly or can be used more easily, and not all our clients see the need to invest in Big Data to the same extent. So you could visualise these trading ideas in real time on screen as a stream of messages, or you could generate the messages relevant to a customer only when you are talking to that customer, with a panel of ideas appearing as a sidebar on the screen, say.
Q: I know that Business Driven Development (BDD), like Agile, is important to the way you work. Can you explain why?
A: It means that you are giving the customer what they want. It’s a process of validating against their acceptance criteria. Obviously every business in a sense wants to give the customer what they want, but BDD implies that: ‘Given a pre-condition state, When something changes to that state — for example a tenor — then the new state should match the acceptance criteria.’ That leads to a focus on the acceptance criteria for what we are doing and when it works it means that right at the start of each sprint of the project I can also start writing the tests and automated tests for that sprint of a project before we even start the coding. BDD in a sense grew out of Test Driven Development (TDD) whereby you literally write the test before you start. The difference is that TDD is writing unit tests to a very granular level — does X x Y = Z and how does that format as a percentage, described to two decimal points etc. ,You know what the acceptance criteria are for the result. With BDD it is business driven development where you are not just meeting the acceptance criteria for the individual code units, it is the features of the product. So you need to use natural language to describe that. The great thing about JBehave [an open-source Java-based framework for BDD] and other tools is that you can create story files, and the story files map to business features on the site you are developing. If you do it right, then when you write that acceptance criteria you’ve pretty much written your documentation for the system as well. We also use Serenity [an open source application for automated integration testing], which matches JBehave with WebDriver [a tool for automating testing of web applications] which allows us to test websites in what we call a BDD manner. We can integrate that into CI [Continuous Integration]. That process then runs all the unit tests and all the acceptance tests; it builds the application, then deploys the application, and it then runs the integration test against the deployed application. We know that every time we change anything, the whole will still work. Serenity helps us to communicate the process to the customer very simply. It comes with a pie chart, divided in green, blue and red, that shows you tests that pass, tests that have not run or are not implemented yet, and tests that fail. It allows you to take a screenshot every step. You want an audit trail? Just look at the pictures. Our customers love that.
Q: How do you integrate UX into the process?
Usually the UX team is part of the pre-sale process, meeting the client with the product owner. They will talk to the customer and mock up some screens so they can actually see what they want. Then the product owner will talk to them and say “Actually we’ve got that on the roadmap already”, and then we just drag it a bit forward. Or maybe it’s something that we could have on the roadmap but we need to know that the customers are interested. I would say that with UX, you should always do some manual exploratory testing. The human eye is really good at matching patterns and you really have to trust that when you or the customer sees something that looks wrong, then it really is wrong. Automated testing, on the other hand, is really looking for particular strings of code, which cannot achieve the same thing. There are some automated tests for matching visuals, but I don’t particularly like using those. They have to be fuzzy matches and they could be wrong. I always start off exploratory testing simply by clicking around and seeing what happens (i.e. trying to break something). I’m surprised if nothing breaks.
Q: Do you ever outsource testing?
No, we have never had to. We’ve been automating testing for a long time and we’ve been doing Agile for maybe 10 years. The challenge with automation is to ensure it is reliable and that we can trust the tests. Right now I’m very pleased to say that while we have dozens of builds going on across out key platform products the screens are all green at the minute, and the team is rightly proud of that. We have unit tests, which are very specific tests for things like decimal points, we have integration tests, which test the entire build, and then between we have acceptance tests, which are like unit tests for business level features. There will be acceptance tests for for every business-level feature – probably hundreds or thousands per product or project in total. An acceptance test might take the case of a ticket and by varying the parameters tile we can apply different scenarios based on what you might expect to happen for different types of trade. Using Selenium to run a single test might take between one and three minutes, but by pushing the acceptance tests below the GUI layer we can run them in fractions of a second. So it’s not just automation– it’s automation that doesn’t take hours. The message is: “Don’t stop just because you’re automating. Carry on and look at how you can automate in different ways and on different levels.” A typical product’s front-end tests used to have to be run overnight, but now they’re done in between 40 minutes to a couple hours, depending on how many browsers you’re testing. Faster feedback allows you to find, and adapt to, any test failures more quickly.
Q: What about the way your customers test your products — what trends do you see there, and if they are not automating to the same level is that a problem?
Our customers will have their own testing department and they would always do their own UAT testing. They might use our integration tests, or they might want to write their own. I would say they tend to have more manual testers than automated; but we are evangelical about automated testing and that’s the direction we are encouraging them to go. Certainly we are seeing increasing levels of automated testing with customers, but there will be times that we are using different tools. So we are using Java and Serenity and open source tools, and they might have brought in particular suppliers that work, say, with Microsoft products. So we might have to change the code to get the tests to work. It can be a question of the different tools that people use and the different development environments they are used to working in. Agile also means you are in a position to respond the new technologies your customers are adopting, and that is especially true in the JavaScript environment. Our bank customers are increasingly familiar with JavaScript libraries. What about mobile trading? Is that something your customers want to do? Everyone is interested in mobile, and as digitisation progresses it is bound to be increasingly in demand. But it is not an easy space because of security concerns — you need to have some sort of two-factor authentication to properly do mobile and ensure that the person doing the trading is who they say they are. Maybe that’s some sort of fob that attaches to the device that matches against a key, or whether you have some other system, whereby the user logs in, and it sends you an SMS with a code that has to be entered to continue. Mobile trading will come because there are so many mobile devices out there and customer demand will drive development. People don’t want to go to lunch and not be able to get out of a position. Mobile is prevalent in retail banking so its simply a matter of time when it becomes mainstream in capital markets and treasury systems.
Q: What else is on your horizon?
Blockchain is definitely a hot topic. What it would mean for us is another third party integration. There are some different initiatives for establishing standards between banks and we’ll have to see where the banks’ investment goes. The big issue that has to be thought through is how you balance the need for knowing and trusting the participants in any Blockchain exchange with the need to avoid the situation where a group of participants has too much control over the ledgers and so the pricing. It’s one to watch.
