Numerix LLC

Article / Updated 07-25-2022

In this article, we look at some business types in more detail to see how traditional financial firms are being shaken up — and improved — by FinTech disruptions. What is FinTech? FinTech is an overarching term for the combination of finance and technology. However, within FinTech, many subcategories apply to specific sectors of the financial world. Here’s a quick summary of them: Capital Markets Tech, in which companies leverage newer technology such as artificial intelligence, machine learning, and blockchain, is led by seasoned capital markets veterans and is both collaborating with and disrupting the financial services incumbents. WealthTech unites wealth and technology to provide digital tools for personal and professional wealth management and investing. This sector includes brokerage platforms, automated/semiautomated robo-advisors, and self-directed investment tools for individual investors and advisors to navigate the changing landscape in wealth management. For more information, check out The WealthTech Book, edited by Susanne Chishti and Thomas Puschmann (published by Wiley). InsurTech is a combination of insurance and technology. It refers to innovations that generate efficiency and cost savings from the existing insurance industry model. For more information, see The InsurTech Book, edited by Sabine L. B. VanderLinden, Shân M. Millie, Nicole Anderson, and Susanne Chishti (published by Wiley). RegTech is a community of technology companies that solve regulatory challenges through automation. The increase in major regulatory policy and the rise in digital products have made it imperative for companies to check for and implement compliance issues, and this can be difficult with old, manual processes. For more information, refer to The RegTech Book, edited by Janos Barberis, Douglas W. Arner, and Ross P. Buckley (published by Wiley). PayTech refers to the combination of payments and technology. Innovative payment services now form part of the PayTech ecosystem and have dominated the early days of the FinTech revolution through mobile, cross-border, peer-to-peer, and cryptocurrency payments. Financial institutions have had to digitize their current offerings to create new channels linked to a digital platform. For more information, see The PayTech Book, edited by Susanne Chishti, Tony Craddock, Robert Courtneidge, and Markos Zachariadis (published by Wiley). AI in Finance refers to how artificial intelligence, machine learning, and deep learning are applied across financial services companies today and how they could be used in the future. For more information, see The AI Book, edited by Ivana Bartoletti, Susanne Chishti, Anne Leslie, and Shân M. Millie (published by Wiley). LegalTech combines the nature of legal technologies and their relationship with data, the Internet of Things (IOT), cybersecurity, and distributed ledger technologies as well as ethical considerations of the technological advancement. For more information, refer to The LegalTech Book, edited by Sophia Adams Bhatti, Susanne Chishti, Akber Datoo, and Drago Indjic (published by Wiley). Banks Some larger financial institutions have adopted the phrase “We’re just a technology company that happens to have a banking license.” This is mostly a marketing gimmick, although it’s perhaps partially true for some of the new challenger banks that are attempting to disrupt the incumbent banks. However, with customer acquisition costs high and increasing regulatory hurdles to surmount, new challenger banks need to decide whether they will build their technology stack themselves or work with FinTech partners to develop the innovation required to topple the incumbents. The financial institutions that are effectively managing this move to become FinTech companies are those that understand how to move quickly to deliver what the consumer needs in an industry on the verge of further change. Most of those who succeed have taken a hybrid approach, focusing on partnerships, acquisitions, and internal initiatives. Several incumbent banks are known to be developing new digital-first products in a bid to keep the new wave of challenger banks and providers in the background; an example is Bo from the Royal Bank of Scotland. They are also gradually adopting much more ambitious cloud-based platforms (despite their paranoia about their data being hacked) on which they can offer or launch numerous products. These initiatives are being supported by the likes of Amazon, Google, and Microsoft, which provide cloud hosting services and enable banks to develop core banking Software-as-a-Service (SaaS) platforms with the required encryption security. Asset management Traditionally, serious investors have valued personal investment advice from human experts, and they haven’t minded paying for it. However, the asset management industry has been attacked from two different angles: One of these is the march toward passive investments (such as exchange traded funds, or ETFs) over active asset management. ETFs are traded like stocks where the holdings track to some well-known index, such as the Standard & Poor’s (S&P) 500. The other is the rise in popularity of robo-advisors, which use ETFs as a strong part of their strategy. A robo-advisor is an investment selection tool that uses algorithms and machine learning to offer investment advice and management to users. The trend toward passive asset management has been apparent for some time in the retail/business-to-consumer (B2C) space, but we’re lately also seeing it with the larger business-to-business (B2B) investors as the stock market index returns continue to rise and they are looking to cut costs to further enhance returns for their clients. WealthTech firms are enabling investors to self-manage their portfolios by offering users technology-enabled tools to help make investing decisions. These tools can include full-service brokerage alternatives, automated and semiautomated robo-advisors, self-service investment platforms, asset class specific marketplaces, and portfolio management tools for both individual investors and advisors. They consider not only investment opportunities but also factors such as a user’s goals, income, marital status, and risk aversion to differentiate on their offering. They enable those who can’t afford a traditional financial advisor to have similar — if not more informed — advice at a lower cost. Insurance If the banking and asset management firms think they have it tough with the rise of FinTech firms, there are many that believe that the insurance industry is even more prone to disruption — and innovation. InsurTech firms initially started to explore offerings that large insurance firms had little incentive to pursue. For example, they offered customers the ability to customize their policies, and they used internet-enabled devices to collect information about behavior (such as driving habits) that could be used to dynamically price insurance premiums. Traditionally, the insurance market has worked with relatively basic levels of data to group respective policyholders together to generate a diversified portfolio of people. However, InsurTech firms are tackling their data and analysis issues by taking inputs from various devices, including GPS tracking of cars and activity trackers on wearables so that they can monitor more defined risk grouping and therefore allow certain products to be more competitively priced. In addition to better pricing models, InsurTech firms are using highly trained artificial intelligence (AI) to help brokers find the right mix of policies to complete an individual’s insurance coverage and credit score. In some cases, they can replace brokers entirely, further disintermediating the process (and saving costs). Apps are also being developed that can combine contrasting policies into one platform for management and monitoring. Some of the benefits of that might include enabling customers to purchase on-demand policies for micro-events and enabling groups of individual policyholders to become part of a customized group that is eligible for rebates or discounts. Insurance is also a highly regulated industry. Major brokers and underwriters have survived by being both prudent and risk averse. They are therefore suspicious of working with InsurTech start-ups, particularly those that want to disrupt their stable industry. Many InsurTech start-ups require the help of traditional insurers to handle underwriting issues, so the incumbent players here are likely to collaborate with and invest in their junior partners. Regulation and legal work RegTech is the management of and compliance with regulatory processes within the financial industry, using technology to address regulatory monitoring, reporting, and ongoing compliance. The predominantly cloud-based, SaaS offerings to help businesses comply with regulations efficiently and more cheaply act as the glue between the various sectors of the financial services industry described earlier. LegalTech describes technological innovation to enhance or replace traditional methods for delivering legal services across financial services and beyond. This innovation includes document automation, predictive artificial intelligence, advanced chat bots, knowledge management, research systems, and smart legal contracts to increase efficiency and productivity and reduce costs. With the use of big data and machine-learning technology, RegTech and LegalTech firms reduce the risk to a financial institution’s compliance and legal departments by identifying potential threats earlier to minimize the risks and costs associated with regulatory breaches and any legal work. RegTech firms can combine information from a financial institution with precedent data extracted from prior regulatory events to forecast probable risk areas that the institution should focus on. LegalTech firms can help financial institutions draft documents, undertake legal research, disclose documents in litigation, perform due diligence, and provide legal guidance. These analytical tools can save institutions significant time and money, including saving them from having to pay fines levied for misconduct. The institutions also have an effective tool to comply with ongoing rules and regulations specified by financial authorities, which are constantly prone to amendments. Payments From banknotes to coins to plastic cards and mobile devices, payments have evolved over the centuries to include a number of ways to help financial transactions take place between individuals, institutions, and governments. Payment technologies and global infrastructures that facilitate payments around the world also are changing. Over the last few years, mobile money has helped millions of people in developing countries get access to the financial system and tackle the goal of financial inclusion. Digital and cryptocurrencies such as Bitcoin, Ripple, and Ether have also entered the payments sector, which is innovating more rapidly than ever with the goal to move value cost-efficiently in real time and at near zero cost. As a result, the PayTech sector is booming; established players closely work with newcomers as there is no end to the creativity of the PayTech and payment industry.

Article / Updated 09-24-2020

The financial services industry is in a state of massive disruption lately, in this post-financial-crisis era. Venerable, traditional financial institutions are on the defensive as new upstarts change the playing field in fundamental ways. This disruption is a growing concern for financial services firms at risk from potential displacement by nimbler, data-driven competitors, including those in banking, capital markets, insurance, and wealth management, and is forcing them to evolve to remain competitive. Some of this disruption is coming from the perception that BigTech giants, such as Amazon, Ant Financial, Apple, Facebook, and Google, are likely to roll out industry-changing platforms and technologies that compete with more traditional offerings. However, emerging FinTech start-ups are also challenging the status quo by providing innovative services and increased personalization, particularly in the consumer space rather than the wholesale arena. FinTech, which is shorthand for “financial technology,” is the drive to bring transformative and disruptive innovation to financial services by applying new and emerging technologies and satisfying consumer needs through automation. Traditional financial services institutions are right to be nervous about the growing successes of FinTech firms. By their very nature, FinTech start-ups have a number of advantages. Here’s a brief comparison: For starters, FinTech start-ups are nimble. Because they aren’t disadvantaged by inherited older systems and methodologies, they can move faster to create new solutions. Their top leadership is also focused on creating the future, rather than maintaining the status quo, so they aren’t resistant to investing heavily in technological development and innovation. In contrast, traditional banks, brokers, and asset managers have weighty existing systems to support, limiting what they can spend on innovation. They are also subject to greater regulatory and institutional constraints that limit their ability to fully focus resources on new technology. FinTech companies must provide trust and value Both consumers and businesses select financial services using two basic criteria: Is it a trustworthy institution? Do the services offered meet my needs at a competitive price while providing value-added services that make my life easier? Because of this, every financial sector firm faces the same basic challenges today. They are all trying to restore public trust in a post-financial-crisis environment, deliver the services that customers want, and offer the customer an attractive value — all while still making a profit. Trust In today’s environment, a “trustworthy” financial institution is one that can be relied on to hold up its end of the relationship by being a responsible steward of the customer’s assets and information. This means safeguarding every aspect of the relationship, preventing harm from both internal and external sources. This can include Maintaining the financial services company’s ongoing solvency and success. Nobody wants to use a financial services company that might go out of business at any moment or that doesn’t have the resources to invest in the latest and best capabilities. Safeguarding the customer’s investment, both physically and digitally, maintaining effective vigilance against data thieves and saboteurs. Cybersecurity is critical for this point; a cybersecurity breach that exposes customer or supplier data can damage an institution’s reputation irreparably. Safeguarding the customer’s privacy. Customers want to know that their sensitive financial data is going to stay private and not be compromised by hackers or careless internal handling. So, who has the edge in this area: traditional institutions or FinTech start-ups? It’s a mixed bag, because they both bring advantages to the table. Customers may perceive large, traditional institutions as being more trustworthy because of their history and gravitas, and a large, well-established business may be more solvent and less likely to crash and burn (although it’s no guarantee, as we’ve seen in recent years). However, FinTech start-ups may actually have an edge on the data-safeguarding front because of their focus on the latest technologies. Value The second part of the equation is the services and their value. What does the financial service provider bring to the table that the customer wants? In an ideal world, the customer wants all the services, and all the options for receiving them, for the lowest possible price. The challenge, then, is to be the provider that best meets that demand. One way that providers are able to offer greater value to customers is through disintermediation. To disintermediate means to cut out some or all the steps between two points — in other words, to “cut out the middle man.” Financial services traditionally has had lots of intermediate steps between a consumer’s need and its fulfillment, creating lucrative careers for stockbrokers, tellers, credit card processors, personal bankers, and even check-printing companies. However, in today’s market, disintermediation is becoming not only the norm but a near imperative to keep up with demand for lower costs and better value. Fortunately, advancing technology has made it possible to automate many areas of the financial services value chain that were strictly manual operations in the past. This has enabled companies to economically provide services to customers that were expensive in the past due to the labor involved. In this endeavor, FinTech companies are better positioned than their traditional counterparts. They can be more responsive, more focused, and less distracted by legacy issues such as fixed cost, old infrastructure, and dated technology. The established players have been slow to respond to FinTech’s disintermediation and disruption because they haven’t wanted to cannibalize their legacy franchises. Many have attempted to offer digitalization only in noncore businesses or geographical areas. For example, some large banking institutions have experimented with offering new experiences such as payment services that compete with FinTech payment providers. However, these new offerings often require significant investment in new technologies to “get in the game,” such as mobile-friendly site design, cryptocurrency, and digital wallets. They must respond to continually advancing technology, changing consumer habits, and in some cases underserved and underbanked markets. In China, the most successful FinTech firms have been BigTech companies that developed financial ecosystems in conjunction with their highly engaged consumers. One example, Ant Financial, was created on the back of Alibaba’s e-commerce platform, offering online payments, investments, digital banking, lending, and wallets. This was possible because China’s FinTech ecosystem is fundamentally different from that of the United States and Europe. In Western economies, successful FinTech firms have been disruptors, particularly in the payments, lending, and wealth management sectors. They have benefited from extensive consumer adoption of mobile technologies and internet access. Ant Financial is closer to the notion of TechFin rather than FinTech, where a large technology firm leverages its technology prowess to deliver financial products within its more efficient, broader service offering. It can also do this because it has generated a level of trust with clients that was previously reserved for traditional financial institutions.

Article / Updated 09-24-2020

If you’re going to use open source in your organization, it’s critical to have a well-thought-out plan for doing so. There are many moving parts and many factors to consider when developing an open source strategy. This article summarizes some of the factors that may make a difference in how you want to proceed. Your Business Model Before determining the place for open source in your company’s plan, take a careful look at the company’s business model, current needs, and future goals. A FinTech company can help you identify what technologies are available, what the new trends are in the industry, and what future areas of growth you may want to plan for. You should also think about what open source can offer and how those offerings fit with the company’s goals. Some of the most compelling benefits open source can potentially offer include Speeding up development and time to market Reducing overhead Removing redundancy Increasing efficiency However, those benefits don’t just magically materialize. The company must take a comprehensive approach to open source usage and management within the company’s structure. This includes having versioning and provisioning processes and takes into account the company’s general tolerance for oversight. Open Source Community Health Keep in mind that one of open source’s great potential benefits is the large pool of expert users who share their expertise and updates with one another. Therefore, one important consideration when looking at a particular open source solution is to what extent you’ll have access to such a community. Here are some easy benchmarks for evaluating the health of an open source community: How well is the project site developed? Have the project site owners thoughtfully curated the resources and tools provided? Is there a ticketing system? Is the documentation well-conceived and regularly updated? How many releases have there been and over how many years? How many forks in the code have taken place? How many contributors have there been over time? How many users are there? How well known is the code outside the project home? Have there been any financial contributions/donations over time toward maintaining and further developing the project? Do any large corporate users contribute to the code or its support? How many maintainers are there? How much has the code changed over time? Are any statistics available about the code’s return on investment (ROI)? How many organizations contribute to this project? How often are there new releases? How often is there code review? How many regressions have there been over time? How many bugs? A good project site should be able to supply answers to all these questions. Tech Support Open source doesn’t follow the traditional support model. No single company is responsible for after-development support. Instead, a community of users and developers have freely assumed the responsibility of providing support and bug fixes. Technical support for open source code can be problematic if the code doesn’t have an active user community, as we say in the previous section. An active user community can offer information and support that enables a company to deploy a stable open source code logically and systematically. The factors we list there can reliably indicate the code’s stability and quality because they point to there being people who care about the code and its viability. You must do your due diligence and research to determine the community health and, by association, the prospects for getting good technical support. Keep in mind that the online user support community isn’t your only option for technical support. If you’re deploying a whole open source system, versus utilizing a small snippet of code, your expectation of support may be different, and you may opt for different approaches: For large deployments, it may be beneficial to have in-house support. On smaller projects, it may be possible to subcontract support directly from project’s owner/creator or maintainer. If you’re embedding open source in your proprietary software, you must weigh the risk of having no control against the level of support and the level of error fixing for the included open source code. Security Depending on how you plan to use the open source code, its level of available security may be inconsequential, critical, or somewhere in between. It’s important that you know your company’s security requirements and then compare them to what the product or code provides. One important security consideration is how well the code has been tested/proofed against security attacks. Several out-of-the-box “defects and analytics” tools are available that produce static security reports. These tools reveal possible defects in the code and report them back to the project maintainer. When reviewing a project portal and its documentation, it’s important to note whether you can easily report bugs, review the security protocols, and review any reports of vulnerabilities. Vulnerabilities should be included in the release notes. Some vulnerabilities are extremely common and readily identified, and any good development process avoids them. Finding such vulnerabilities in an open source product after its release can indicate sloppy development. The open source world has no quality assurance standardization, so all open source code comes “as is.” You shouldn’t release or use anything that your own company’s quality assurance process hasn’t validated. Also, no centralized database lists open source vulnerabilities. There is, however, a National Vulnerability Database (NVD) that collects vulnerabilities as they are known. Unfortunately, this database often points out vulnerabilities to hackers, who then exploit them. Most deployed open source is checked against this database, either manually or using automated tools, and any vulnerabilities found are fixed quickly. Someone in your organization should be responsible for reviewing this database and managing any needed changes on a weekly basis. Code Audits Many organizations are hesitant to use open source code because of the potential for operational and security risk. Such risks can be minimized by regular and rigorous code audits. Open source code audits are important for two reasons: They expose any potential security concerns, and they expose any potential infringement issues. Not only must an organization have policies governing software selection, vetting, and review, but it must also demonstrate an understanding of the potential interdependencies entailed in the actual use and deployment within a larger framework. Auditors typically look for more than a simple spreadsheet as proof of proper oversight. To survive an open source audit, a company must demonstrate that it has educated its developers on the proper processes to follow before using even one line of open source code. There should also be a centralized repository of all contracts associated with open source that counsel has reviewed. Staying on top of releases of open source code is crucial to the success of surviving an open source audit. A company’s policies and tools should require regular open source code review. The primary purpose of such a review is to verify that the code has been updated with latest releases and that any known vulnerabilities and errors reported have been fixed. This review should entail Listing all open source components, the version in your product, and the most current version available A list of vulnerabilities associated with those components A scheduled date by which to remediate any critical issues Reliability When selecting open source software or code, future sustainability is of major concern. Open source code is sustainable only if there are dedicated user and contributor bases. Open source, like all code, has a life cycle, so it’s not unusual if the number of developers decreases over time, as long as the consumption of the product doesn’t wane. You can easily gauge the value of open source code by simply using standard internet search tools. Social media also supports open source discussion through blog posts and articles discussing projects. Narrow down your selection to three possible candidates by using this checklist. If your open source candidate holds up positively to these questions, it will pass most internal and external audits: Does it have a large user base? If so, it’s likely to have strong support and a good likelihood of longevity. Does it have a good reputation? Reputation isn’t everything, but it is important. Is it interoperable? You want to be able to use this code easily. Does it require specialized skill to use or maintain? If so, maintenance could be costly. Does it have sufficient, well-written documentation? Because contributors to open source have varying skills, review of documentation is critical. In fact, the use of the documentation to support the code should be part of the quality assurance (QA) done on the open source code before it’s incorporated into production. Has it used open standards? Code built on open standards and practices is easier to maintain. Does it have a good support network? A support network can include not only a user and developer community but also paid support options. How often has the code been updated since its inception? What is its most recent update? Frequent is better. Is the project site well trafficked and well maintained? Does it exhibit good governance and community participation? A review of release notes and user statistics can help in determining this. Is the open source license associated with the product clearly defined? Your legal counsel should review it, and you should make sure no conflicts occur with other open source agreements. Is there any larger group behind the development of the project? A large company that relies on the code or regularly contributes to it is a benefit. Hidden Costs Open source is appealing because there’s an implied understanding that it’s “free.” But as we say, nothing is ever really free. You must understand the open source offering and the organization’s needs before you can understand its potential costs. On the surface, there appears to be savings from the outset because you pay nothing for the license and use of the code. There are hardware, maintenance, support, and legal costs, but these too may be less expensive compared to enterprise third-party offerings. Cloud strategies and the use of open source platforms can eliminate some of the network overhead. Though the use of these items isn’t free in that development and deployment costs are associated with them, they should be significantly less expensive than in-house company-owned equipment. There are also other intangible benefits in using open source. For example, faster development time is a real and quantifiable benefit. To understand and manage costs, take a look at the following areas of setup and maintenance, where there can be ownership costs, and determine ways to control and scope them prior to making a commitment. Setup costs include the following: Hardware: Review the project site for hardware recommendations and make sure you have them on hand. If not, the cost of the hardware will need to be built into the budget. Integration: The size of the project will determine the size of the staff. If it’s an application, outside resources may be required. Create a deployment project plan. Analyze interfaces and interoperability. Specialists may be required. Replacement: If this is a replacement strategy, you must understand what components are needed. Data transfer can be time-consuming and may require specialists. Customization: Open source doesn’t mean “one size fits all” out of the box. You must budget for developer costs to modify code to fit your unique needs. Training: New software implies new training and perhaps some slowdown in productivity. Maintenance includes the following: Updates: Someone will need to rigorously monitor the project site for available patches and releases and take charge of applying them. Customization: Any customization your organization does to the code will require support throughout the life of the product. Support: User and developer support must be available throughout the life of the product. When selecting open source software, pay special attention to these areas that may necessitate additional expenses: Interfaces: Because of poor user interfaces, less and inconsistent documentation, and lack of training, there could be increased time spent on administrative functions with some open source products. Support complaints: Because of the lack of designated support and inconsistent documentation, your internal team may spend more time on troubleshooting. Bug fixing: Because not all open source projects have a standardized approach to QA and regression testing, your in-house team may be responsible for finding and fixing bugs themselves. Additional development: After you’ve implemented an open source solution, you may find that you need further code development due to some unanticipated issue, such as poor network performance. Extensibility: There are no guaranties that any code will be future-proof. The only insurance you may have is that the code has been built on the latest flexible architecture in any easily utilized language. Updates and upgrades Through new releases, programs get new functionality, bug fixes, and higher levels of security and usability. However, with open source, there’s also a more pressing reason that updates and upgrades have to be current — the code is open to all. Anyone can see it when issues arise, including hackers looking for vulnerabilities they can exploit. When a vulnerability is found, it’s published to the project and later to websites that list all open source vulnerabilities. These lists are fodder for hackers. Luckily, you can use tools — such as Zoho, Bugzilla, and MantisBT — to make sure that you don’t miss updates and that check against the current open source code you’re using for vulnerabilities and severity of them. With internal accountability for fixing issues as they occur and resubmitting them back to the project, you can handle maintenance and security with minimal risk. Updates and new releases should go through proper quality assurance. Because no standards are established in open source for quality control, it’s your company’s responsibility to see that the standard of the open source code meets the company’s quality standards. When engaged in updating or upgrading, note that backward compatibility isn’t a given. Testing is a requirement to guard against fatal errors caused by version conflicts. The compatibility issue becomes more complicated when there are multiple uses of different open source projects. In such situations, you should test open source components in the actual environment they function in rather than in isolation. To avoid the risk of vulnerability attacks and of third-party update incompatibility, your company will need to take a regimented approach to updates and releases. The regimen should include a calendared weekly review of all open source updates. You can automate this process using code management tools. All security issues and bug fixes should be prioritized for immediate updates as determined by their level of severity. New functionality should be prioritized according to business needs. There should be a centralized repository that developers use for all open source code. By limiting the accessibility to the open source code to one repository, you avoid the possibility of different teams using different versions. Educational reviews of all open source products in use should be shared with the development teams on a scheduled frequent basis. Potential hardware impact The ever-increasing demand for real-time computation has driven companies to search for cheap compute environments. As virtual servers and in-the-cloud burst delivery mechanisms are replacing brick-and-mortar server sites, it’s important to understand the costs involved in moving away from physical on-site environments. FinTech companies are well situated to advise members of the financial industry about tactics and strategies to be used to reduce operating costs and still deliver as near to real-time analytics in the areas they are required. Speed isn’t a requirement for probably 80 percent of the data store and manipulation that goes on in most financial firms. With that said, open source has often been a trailblazer in the area of reducing costs by creating and facilitating “free” operating systems. There are of course costs associated with the creation of hardware, which has made open source hardware development projects challenging to achieve. Even with its success, Apache’s web server and Tophat are funded only through corporate sponsorship and user conferences. With the cost constraints around creating free open source hardware (FOSH), FOSH projects rely on the community to build hardware based on the intellectual properties developed (such as data layouts, integrated circuit schema, mechanical drawings, and so on). The academic community has driven FOSH’s creation and development to date. Its hardware development artifacts are captured via hardware description language (HDL). However, utilizing open source software code with open source operating systems and the available security and efficiency tools can result in significant savings. Cost reductions have been reported as high as 44 percent for hardware costs based on intelligent strategies around open source, cloud-based deployments and virtual servers. Legal considerations Open source/free licensing contracts test the complexity of good governance and legal adherence. Unfortunately, there isn’t a one-type-fits-all generic contract available for open source. Another layer of complexity becomes apparent when reviewing all open-source contracts a company uses. The contracts often have interoperability issues with each other. And finally, international use of open source may raise other legal restrictions that have to be understood and resolved. When reviewing the licenses associated with open source, pay particular attention to the following: There should be no audit rights that reach into an organization’s network directly. There should be no fines associated with the inadvertent deployment of unlicensed open source code. See whether you can purchase an outside warranty for the open source used. There are no warranties with open source code. If you use it, the liability for it lies with you as the user. Check to see whether conflicts exist with the use of libraries within the open source code. Make sure there are no requirements to provide written notification of initial ownership or code creation within the code. Make sure there are no restrictions on the use of proprietary code with open source. Be sure to check the open source project for pending legal actions. Your rights aren’t protected should a lawsuit be launched against a project; your right of use may be obstructed. There should be regular training about the policies around the use and maintenance of open source for users and developers. Copyleft is the most common version of an open source license agreement. It allows anyone to change the code, but code the company develops as part of that open source can’t be repackaged as third-party or proprietary software. With copyleft, anyone making changes to the code must make the new iteration available to all. Non-copyleft licenses permit developers to make any changes to the code, including retaining the modification as proprietary. Purists of open source don’t like this version because it violates the spirit of open source and restricts the sharing of all functionality as it’s developed. Corporations, of course, would like to retain control over what they pay their developers to create. Non-copyleft code is therefore more acceptable to corporations and for projects needing fast and ubiquitous adoption. One of the issues with non-copyleft code development is that new functionality may not be resubmitted back to the project and may result in the original code’s use and growth being stifled due to forking. Maintaining a directory of all open source components in your organization is no easy task. Along with the components, you must also track the license requirements and understand the potential for licensing conflicts. There are hundreds of different types of open source licenses, and the licensee must adhere to terms of each agreement it has accepted. One of the early fears surrounding the use of open source within proprietary software remains a concern today. The broad reach of the open source agreements provides the potential loss of ownership of proprietary software if the proprietary code is inadvertently embedded in open source. This concern can be mitigated only by “best practice” development process, review, and vigilance.

Article / Updated 09-24-2020

FinTech companies are businesses that leverage new technology to create better financial services for both consumers and businesses. Of course, that begs another question: What is financial technology? We define it as all parts of technology that help provide financial services and products to customers. Those customers can be individuals, companies, or governments. FinTech is also frequently used as an umbrella term for various subcategories, such as WealthTech and RegTech. FinTech’s dimensions FinTech may sound simple from the definition you just read, but there are multiple dimensions. You need to think about each of these factors: Which part of finance is being impacted (financial sector)? Which business model is being used? Which technology is being used? FINTECH Circle has coined the term Fintech Cube to describe the intersections of these factors. The following figure illustrates this cube, in which there are three axes: the financial sector on the x-axis, the business model on the y-axis, and technology on the z-axis. Each of these dimensions can be further categorized. For example, this figure expands on the concept by adding key areas of financial services that can benefit from FinTech. All financial sectors are shown on one side of the cube, including retail banking, trading, and insurance (among others). The following figure summarizes the most important business models from business-to-consumer (B2C), business-to-business (B2B), business-to-business-to-consumer (B2B2C), to business-to-government/regulator (B2G), to platform-based business models, crowdfunding, and peer-to-peer (P2P) lending. The following figure shows the third dimension — the technology being used, which can range from cloud computing, big data, artificial intelligence (AI)/machine learning (ML), blockchain (distributed ledger technologies), the Internet of Things (IoT), quantum computing, and augmented and virtual reality. FinTech start-ups, for example, can now be more easily categorized and compared. For example, you may have a retail banking (financial sector x-axis) solution focused on the business model of B2C and using various technologies, such as cloud, big data analytics, and AI. Such a company would be called a challenger bank, sometimes also referred to as digital bank or neo-bank. As another example, you may have a WealthTech company that sells its software to hedge funds. You could describe it as being focused on asset management (x-axis), B2B business model (y-axis), and using several types of technology from the z-axis in combination. What has changed in FinTech There have been tremendous changes in the financial technology landscape in the last decade. Consider the following: Just 20 years ago, it would have been very expensive to launch a FinTech company, whereas today the required expenditure is much more affordable. The decreasing technology costs have reduced the barriers to entry. The funding landscape is also different now. Twenty years ago, there was little funding available for early-stage FinTech firms, but today venture capitalist and corporate venture arms of both financial institutions and tech companies invest large sums in scalable FinTech companies. The industry dynamics have also changed. Previously, technology suppliers to financial services firms were seen as pure vendors. Lately, there has been a powershift in which FinTech companies, larger scale-ups, and unicorns are clearly seen as partners or competitors to established financial players. Even tech giants such as Facebook and Google, which have historically focused on e-commerce or social media platforms, have moved into the FinTech arena. In China, we have seen Ant Financial and WeChat taking leadership positions with their FinTech offerings, which are integrated into their other services in a seamless way. Established financial institutions should read this book to understand how the tech giants embraced the digital age and transformed the industries they now dominate. They need to appreciate how they can adopt their own transformation rather than be disrupted by new firms entering the industry. Traditional banks have already seen their revenues and margins decrease as FinTech firms have undercut their prices on, for example, foreign exchange, lending, payments, and traditional banking services, particularly as open banking is promoted by regulators. Asset managers have already seen their margins reduced by a move to passive rather than active asset management, but this has further developed into robo-advisors that use algorithms to disintermediate financial advisors and portfolio managers. Equally, the insurance industry has found that companies using predictive analytics, based on big data access, are better able to price and manage risks than they have. In all of these organizations, boards need to develop new strategies based around digital transformation and innovation teams that will work in conjunction with existing product and business development. They must also work with technology teams to help them determine how they compete in this new environment. Of course, one of their biggest hurdles will be themselves as they need to instill a new culture that embraces change from the top down.

Article / Updated 09-16-2020

Blockchain is one of the tools that FinTech uses in transforming and redesigning banking business processes. Blockchain offers a decentralized data structure with an immutable source of truth that is traceable, tractable, and auditable across the complete history of a transaction or an event. Through automation, it minimizes the potential of human error or malicious activities while reducing costs. Because of all those benefits, blockchain has the potential to disrupt the financial industry. Financial, banking, and insurance companies considering implementing blockchain must understand its value and strategically position it in their digital infrastructure. FinTech fills a knowledge void that enable banks and financial companies to advance a well-planned approach that focuses on needed applications and technologies but does not disrupt the banks or financial companies’ focus on their core businesses. Blockchain will provide benefits most readily to currency funds, capital markets, secondary market trading, and post-trade settlement processors. It will also help eliminate logjams, audit issues, and security concerns in payment and remittance streams, regulatory compliance requirements, securitization, and personal data and identity management. The greatest benefits across all the use cases in the future of blockchain lies in its transparency and its immutable architecture that eliminates manual processes and automates repetitive functions. When considering partnering with a FinTech company to develop a strategic blockchain and application plan, some important questions to ask and answer include these: Is there any component in your business that would benefit from a decentralized data structure? What are the benefits for your business? What are the costs and potential risks? How will blockchain disrupt your business processes, both internally and externally? How does blockchain fit within the bank’s risk management system? Are there any early adopters in your sector that are successfully utilizing this technology? What are the long-term objectives for deploying blockchain technology? Is there a way blockchain will expand the organization’s reach to new markets? What are the short-term wins? How does blockchain fit with other technologies the organization currently needs, such as cloud, microservices, and application programming interfaces (APIs)? A FinTech company should do a current, complete assessment of the state of the organization. After that analysis, it should be able to produce a phased plan for rolling out the needed technologies that demonstrates an understanding of the company’s strategic needs. The plan should offer a holistic approach to replacing and integrating current systems and should present significant use cases for future enhancements. The plan should include steps for addressing legal concerns and regional governance issues and should provide a transition and support plan for making changes to the blockchain network. In some instances, the banking industry has been racing to advance or adopt some cryptocurrency strategy. Because no regulatory agency governs these currencies, banks have an opportunity to engage and set their standards and their own financial regulatory controls. Cryptocurrencies offer many benefits to the banking industry, like lower transaction costs.

Article / Updated 09-06-2020

Where you sit in the investment hierarchy generally dictates what access you have to types investments and what your risk appetite may be. This is also true for the different investment vehicles in the FinTech investor landscape. FinTech CEOs need to know their potential investors very well and select the best ones in terms of capital, business growth opportunities, and long-term exit opportunities. Crowdfunding Crowdfunding is a way for individuals to collectively invest in a business in return for a potential profit or reward by responding to a pitch posted on a crowdfunding website. Crowdfunding can be very exciting for new investors, because they can back young, exciting start-ups and help them raise the money they need to grow. Often multiple banks will have rejected these early start-ups for loans, so these investments can be quite risky. Several types of crowdfunding exist: Loan-based: Peer-to-peer (P2P) lending is provided in return for a set interest rate (such as Lending Club and Funding Circle). Reward-based: Money is invested in return for nonmonetary returns, typically samples of the product developed. This is the type of crowdfunding on sites like Kickstarter and Indiegogo. Investment-based: This entails receiving shares in return for your investment. Investment-based crowdfunding is more the norm in Europe (particularly in the United Kingdom with companies such as Crowdcube and Seedrs) and more recently Asia. Reward-based investment is more popular in the United States due to regulations around investor requirements, although the JOBS Act (May 2016) extended online equity crowdfunding opportunities in the United States. The very nature of crowdfunding lends itself to B2C-type investments because individuals can relate more to a consumer-focused application (see the earlier section “Understanding the Players” for more information). The product being developed may be something they’d use themselves. Hence, companies may raise a relatively small amount of money from hundreds or even thousands of investors, which in total gives them a decent funding round. Crowdfunding platforms will give you a choice of many companies that need money to grow. The most popular sites make it fun and enjoyable to browse these exciting companies and their products, therefore making it easy for you to part with your money. However, you should never invest money you can’t afford to lose because you may not get it back, and you should invest only in what you completely understand. The amount of due diligence retail investors do is relatively light, given the funds invested. However, firms on such platforms have increased the amount of information they provide, giving a certain standardization around the type of investor presentations produced. The platforms also have an obligation to undertake a due diligence process before allowing companies to list on their sites. The crowdsourcing model is so new that good data isn’t yet available to understand how the majority of the firms on such platforms perform from a return on investment (ROI) perspective. Fewer B2B companies are available for investment on crowdfunding sites, particularly FinTech companies, because B2B technologies aren’t as immediately appealing to casual investors. A revolutionary new electronic gadget is just more “fun” to invest in than technology required for workflow processes within a financial institution. And that’s why we need angel investors! Read on. Angel investors An angel investor is an accredited investor who provides financial backing, networking, business expertise, and other support to a small start-up in return for an equity share. Angel investors are typically sophisticated, experienced investors with high net worth and lots of readily available capital. Angel investors are more likely to invest in businesses that are pre-revenue and seeking seed capital, because they tend to invest in businesses where they feel that they can add value through their domain expertise and network/contacts in that area. Therefore, angel investors generally take more risks than venture capital firms covered in the next section (including investing their own money) and invest more per company than individual crowdfunding investors. However, angels aren’t just guardians. The majority are seasoned professionals who regularly take positions as nonexecutive directors within the firms that they invest in or provide advice and networking to further the firms’ opportunities. In addition, many angels invest collectively as a group or syndicate, either within a given theme, such as FinTech, or within random groups coming together under the guidance of one angel who acts as the lead investor. Europe’s first angel network focused on FinTech was established in 2014 by the FINTECH Circle, where the best FinTech start-ups apply to pitch to experienced FinTech angel investors. The application process is very competitive and normally starts with an online application form, from which the best companies are selected and invited to Selection Days where they present in front of FinTech expert investors. The top seven companies are selected to present at the final FINTECH Circle Angel Network. In some European countries, particularly the United Kingdom, both crowd and angel investors receive income tax rebates/reliefs from their investments in start-up firms. This acts as an incentive for some investors to become more active in this space and improves the risk-reward ratio for such investors. In other countries, for example the United States, it’s more common for the start-up companies themselves to receive tax rebates for their research and development investments. Research which tax benefits you’ll get as an investor and/or as an entrepreneur early on. This could make your investments much more attractive/cost effective. Venture capital Venture capital firms do what angel investors do, but they do it on a corporate basis. Instead of investing their own money, venture capitalists (VCs) are paid to invest other people’s money. Managers of the venture funds, known as general partners (GPs), are typically investors who have years of experience investing in and taking minority stakes in early stage firms. That’s what they do for a living, unlike investors in crowdfunding sites or angel investors. GPs are either good at investing or lose their jobs. Venture capitalists receive money from high net worth individuals, family offices, and corporations, all of which become limited partners (LPs) in the fund. Each of the LPs is looking for a diversified but higher return than what they can achieve from less risky investments, ordinarily for a fixed period of up to ten years. The GPs receive management fees (typically 2 percent of funds under management) to scout and invest in the right types of investments, conduct due diligence, and manage the resulting portfolio. GPs and their firms typically take a carry fee (for example, 20 percent) of the performance of the fund (this management fee and performance fee are commonly referred to as “2 and 20”). The remainder of the profit (for example, 80 percent) is distributed to LPs. However, many funds have to achieve a hurdle rate — a return rate that investors must receive before the fund managers can receive their carry fee. For example, a fund’s agreement may specify that the LPs must be paid back their invested capital, in addition to an agreed annual percentage yield, prior to the GP receiving their return. To reduce the number of LPs that a fund services, a substantial minimum investment is typically required, putting such funds outside of the scope of most regular investors. To invest in VCs, you must either be very rich or indirectly invest via a fund that serves as one of the LPs; this is called a “fund of funds” structure. Because they’re investing with other people’s money, VCs tend to invest in businesses that are relatively established, with a given level of annual or monthly recurring revenue, at the Series A level of fundraising or later. Series A is generally the first funding round by VCs; Series B is the second funding round; Series C the third funding round; and so on. Crowdfunding and angel investors are normally investing in seed or post-seed rounds that come before Series A. Some VC firms are lately shifting their focus to later stage investments (called scale-up funding), because the ROI for many funds have been lower than anticipated. Generally, VC investors should anticipate that about four out of ten firms will fail, and another four out of ten firms may return the monies invested. The remaining two firms would therefore need to have returns of 10 times or more to achieve the type of returns expected. The very successful firms are called unicorns, a term that refers to start-up companies that achieve a $1 billion dollar market valuation. To protect their interests, VC firms are more likely to demand preference shares for their investment and receive veto or minority investor rights that aren’t available to other investors. They also tend to act as the lead investor in a funding round, thereby dictating the valuation, total monies raised, and the terms of the investment. Those terms may include the pre-money valuation of the firm, prior to investment, and the post-money valuation, which includes the funds raised added to the pre-money valuation. For example, a firm raising $1 million at a pre-money valuation of $10 million will have a post-money valuation of $11 million. Corporate venture capital As the name suggests, corporate venture capital (CVC) firms are like regular VC firms, but they invest on behalf of a given company. Their initial motive is therefore to invest in companies that will give some form of strategic benefit to the company, either immediately or in the future. As such, they tend to be focused on later stage firms that can bring immediate revenue and/or profitability. Some CVCs also take outside money, where LPs invest alongside them. However, such funds may be split in focus between providing a good ROI to all investors and delivering a strategic benefit to the parent company. For example, suppose that your bank has a corporate venture fund. It could decide to invest in a FinTech company before it rolls out its FinTech app to millions of consumers globally. The bank must decide whether it will immediately separate the funds made available as CVC or whether it will draw down funds from the bank’s balance sheet to support the investment. Draw down refers to collecting funds when an investment occurs, based on an agreement that such funds will be available when the CVC requests them. This decision can have a significant impact on the commitment to the investment, or at least the perception of commitment. The employees who manage the CVC aren’t necessarily rewarded in the same way that a commercial VC would be, with respect to management and performance fees. Therefore, the incentives, and hence the commitment, can be questioned. Good VC investors should make lots of money, because they share the performance fee. However, the manager running a CVC won’t get such unlimited payments. Therefore, if someone is driven by money, he’d probably want to run his own VC fund. Having said that, in principle, CVCs should be better venture partners to FinTech firms than regular VCs, because they have a competitive advantage due to their domain expertise, knowledge of markets, client networks, and technologies. In addition, their stronger balance sheet makes them a more patient investor. They aren’t looking only for mutual growth but also more strategic benefits, such as direct synergies with their company’s business that further drives additional revenue growth and valuation. However, not all CVCs leverage these benefits. Internal stakeholders can question the start-up’s ability to deliver or suggest that they can build the same thing themselves internally. Those that do succeed follow the mantra that “rip and replace” isn’t the solution to managing old legacy systems and that “core and satellite” is a better strategy. Of course, FinTech firms need to consider whether a CVC minority investment gives them the necessary short-term capital injection to meet their scale-up aspirations in conjunction with the corporate “mother ship.” They may find that aligning closely with one large corporate infrastructure reduces their ability to scale into other competing corporate infrastructures due to a paranoia around access to confidential data. In addition, the obvious exit may be full integration into the CVC’s company, which may not give the same return as selling the product on the open market. Private equity Historically, private equity (PE) funds have been viewed as more similar to the traditional asset managers of private investment. They tend to invest in much later stage companies that already have substantial revenue and are therefore less risky investments. (Blackstone buying a majority stake in Refinitiv is a recent example). Not many FinTech firms are sufficiently large to qualify in that regard, so PE activity is more often found in other commercial sectors. PEs have a similar structure to VCs, in that they involve GPs and LPs. However, the pools of capital raised for such funds tend to be much larger, as the company valuations of invested firms are much higher, given the firms’ maturity, revenue, and profitability. PE funds typically have a fixed investment period, typically ranging from seven to ten years. There are similar management and performance fees (2 percent and 20 percent, respectively), although when institutional and ultra-high net worth individuals invest substantial funds, fees are often negotiable. PE funds can also support investments such as leveraged buyouts, management buyouts, and company restructuring, whereby they regularly take majority or outright stakes in a company and use debt to finance large transactions, with the resulting burden of servicing that debt left with the company. They may then appoint management to make the company more profitable and valuable, which may include selling off pieces of the business in a “sum of the parts being greater than the whole” strategy. Alternatively, they may exit the investment through a trade sale to a strategic buyer (for example, Blackstone subsequently selling their stake in Refinitiv to the London Stock Exchange) or to another PE firm, or they may list the company on a stock exchange via an initial public offering (IPO). The world of investors and investing is changing as a result of the FinTech revolution; this area of FinTech applied to the global investment management sector is called WealthTech. For more information, check out The WealthTech Book by Susanne Chishti and Thomas Puschmann (published by Wiley).

Article / Updated 09-06-2020

The process of selecting and implementing the best cloud services for a financial institution can be quite complex and may require specialized education or experience. FinTech companies can be of great assistance to businesses trying to develop long-term cloud and technology strategies. FinTech companies are generally well versed in the complexities of infrastructure analysis, banking and financial industry regulations, and legacy systems. FinTech aids in streamlining and evaluating all systems, whether they are administered in-house or by a third party. A subdivision of FinTech actually specializes in the area of regulations. It’s called RegTech (regulatory technology), and many FinTech firms have in-house subject matter experts (SMEs) who deal in this area or have partner relationships with RegTech firms. To review all applications that support an organization, evaluate the relevance and workflow of each application or tool within the context of the new technologies available in the FinTech suite of systems and services. As you’re reviewing each application, system, or tool, ask yourself whether it should be Kept in its current state with no change? This option would retain the application and data in its current mode. Decommissioned? Cloud strategy evaluation is a good time to retire outdated and unused technology. Refactored? You should determine which applications are important to the organization and rebuild them to conform to the new flexible, lightweight FinTech structures. Replaced? Determine whether it still meets the business’s needs. If not, find and deploy new applications that meet those needs. Reconfigured? Review applications for their benefits and reconfigure those aspects that would be more beneficial in a cloud environment. Repurposed and/or consolidated? Review applications currently on the cloud and how they fit together. Develop a comprehensive approach to building a comprehensive cloud presence, rather than a piecemeal one. “Lift and shift,” a strategy that refers to moving an application from one environment to another without much review or testing, doesn’t work well in a cloud environment. When moving applications or systems to the cloud, you must anticipate some operational change and downtime. It’s generally a better policy to utilize third-party FinTech companies to handle new technologies and systems that aren’t core to the corporation’s growth and focus. FinTech companies make it their business to determine the best architecture, use cases, systems, and tools to implement when integrating a company’s required functionality into the cloud. A third-party FinTech company can assist the corporation in determining the best strategy, as well as do the heavy technological lifting, for cost-effectively leading the company away from its legacy systems and into the cloud.

Article / Updated 09-06-2020

The move toward FinTech has been gradually happening for many years, driven by the high costs of systems maintenance, slow delivery of new functionality, the high salaries and high turnover of developers and specialists, and increased demand for real-time solutions. Take a look at one of the key strategies behind FinTech solutions and innovations—API. What is API? An application programming interface (API) is a set of reusable functions, procedures, and other tools. An API enables a developer to rapidly construct a functionality once and then reuse it in different ways across different applications. For example, an API can enable data transmission across applications in a standard way regardless of the language/media or application type. The efficiencies that APIs provide enable rapid development with low overhead costs. APIs are an essential component in cost-effective application development. To stay ahead of the development curve, developers and senior management in large corporations must strategically plan API environment creation and maintenance. For example, megabanks, such as Deutsche, HSBC, and JPMorgan Chase, have developer portals and APIs to help customers and partners develop tools that interact seamlessly with their data and their workflow needs. Any API strategy has associated development and maintenance costs. APIs take time and labor to create. However, that time and labor is generally made up — and then some — by the convenience and efficiency they provide to the programmers who use them. A side benefit of using APIs is that they allow systems/applications to be built by a third party, because they simplify the programming process. An enterprise should develop an API strategy that consists of public and private APIs and that is well documented and part of all release cycles. To better understand APIs, imagine that you had friends over, and you wanted to serve an Italian dinner. You could assemble all the ingredients yourself and make it, but it would take an hour and a half, and you have only 30 minutes. What do you do? You pull out a jar of spaghetti sauce, boil some water for dried pasta, and buy a prepared loaf of garlic bread. And voilà! Dinner is served. Having APIs in your programming pantry is like having premade spaghetti sauce, garlic bread, and pasta. The components/ingredients needed to prepare the program are all available in the source code. When bundled together, they make up the API. The beauty of APIs is that you can swap out components. If you don’t like spaghetti, you can easily have corned beef instead. Or if a friend wanted something different, he could take the APIs available to everyone and make something out of the same underlying components/ingredients. Anyone using these APIs doesn’t have to know anything about how to cook or assemble the ingredients; it’s all preconfigured for him. The following figure illustrates the concept. As you can see, having prepackaged elements already tested and ready to use speeds up the time to completion of any application. The providing company can choose what it wants to prepackage so the nature of the “secret sauce” (in other words, the underlying code) is never revealed — just the end product. API benefits Providing APIs makes sense because they expand the reach of a company’s core business through user-friendly interfaces and API tools. APIs provide for faster application development and integration, and they increase the ease with which partners and customers can use and develop custom work on the top of the application’s code. Partners and customers can then own those components, which are specific to their corporate needs, and the company can retain and integrate those applications that have universal appeal into their master codebase. By providing easy access to API libraries internally, you can encourage employee innovation and ownership. APIs can also be used to modernize and replace legacy systems more efficiently. APIs make modern digital ecosystems possible. An intelligent approach to creating and modifying APIs helps companies with both internal maintenance and customer and partner accessibility. APIs assist in the integration of data and the streamlining of workflow. By exposing APIs, you can reveal important data to customers and partners without revealing proprietary code. APIs also speed up the development process and make development by external users possible without security risk. Without APIs, your developers would need to support application onboarding, which involves time away from core development work and results in less product creation and a higher cost of ownership to the application. In addition to those core benefits, APIs offer a number of side benefits. For example, they provide clear formatting for development and give the developer the option of ensuring backward compatibility. They also provide a universal way to handle metadata and information brokering for specific applications and/or systems. Developing an API strategy Developing and adhering to a detailed API strategy is critical to an organization’s success. The elements that go into the building of this strategy include the following: Defining the optimal outcomes for API usage both internally and externally Publishing the expected outcomes and approaches to the target groups involved for feedback Understanding and identifying the way your technical teams work Understanding and identifying the systems that the organization, its customers, and its partners use Developing a beta deployment process that includes an easy way to track and support internal and external beta users Developing a feeder structure in which each iteration is first rolled out to “heavy” internal users and then to customers and partners who are committed to using the APIs and providing feedback Assuring that support and maintenance personnel have been assigned and given clear key performance indicators (KPI) around the API framework Tying the successful development and maintenance of this system to all new releases Developing a user group philosophy where external users are encouraged to share and develop user groups and are rewarded and recognized for doing so Establishing an API web portal that includes easy interfaces for gathering user feedback; a repository of new packages and libraries created by both employees and external users; easy access to all documentation; and rapid knowledge exchange Developing a process for version control, tools, and documentation that provides and augments designing, testing, and developing in every release and every API package Offering the ability to license the use of the APIs and to monitor the use against possible security intrusion via the web portal Any standardization practice is only as good as its users. The API strategy, once created, must be adhered to by all developers and participants. Including REST and RAML The API web portal should house tools needed to develop and maintain the APIs. Having such tools available will permit fast development in RESTful API with documentation and an immediate feedback loop. What do we mean by RESTful API? REST stands for REpresentational State Transfer. It is stateless — each action is treated uniquely, there is no record of previous interactions, and it enables plain-text exchanges, rather than HTML, which allows coders to use efficient configuration directives for start-up and saved settings. It also enables security policy inheritance, which allows for the inheritance of as well as adherence to security requirements. RAML (Restful API Modeling Language) allows REST APIs to be formally defined. RAML can define every resource and operation exposed by a microservice. Both tools are scalable and secure components and include a mechanism for creating license agreements that stipulate how the APIs are used. Tools are also available for monitoring the use of third-party developers to guard against privacy and security violations. They also include provisioning tools for logging and updating issues. Trying tips for API success Here are some tips for making sure your API strategy is successful: Recruit from the start. Get buy-in from senior management and appoint a project owner who is eager to evangelize about the benefits. As with all development, it’s important to keep an up-to-date library of use cases and terms so that instead of re-inventing the wheel, you’re recycling and reusing whenever possible. Don’t get bogged down in the minutiae. Build a flexible high-level plan that can be easily altered and expanded. Revisit that plan on a scheduled basis. Each company should develop a calendar that meshes with its development cycles. In general, API strategies should be reviewed at least annually, though some are reviewed at the time of each release. Develop a robust API portal to handle internal and external users — from licensing through downloads and support. Most API downloads are stored and updated on the general product download site. Build a back-end management system. APIs and security vulnerabilities Some inevitable security risks come with implementing a flexible and accessible API strategy. Be sure to review the level of data vulnerability at each point in the process, looking at issues of data controls, movement, and encryption, and either accept or take steps to decrease the risks. Some ways to make systems less vulnerable include the following: Employ a comprehensive licensing mechanism. Create clear requirements around authentication and event logging. Test every release against clearly defined security standards. Use multifactor authentication. Establish clearly defined rules for data encryption.

Article / Updated 09-06-2020

Technology in general is constantly developing, and a number of new technologies are being applied to the financial services arena. This article highlights some of those new technologies and how FinTech firms are putting them to work. Authentication methods Biological authentication (biometrics) is the future of authentication, with authentication methods such as facial recognition, voice recognition, retina scans, and fingerprint scans becoming ever more accurate and widely deployed: In particular, voice biometrics represents a major step forward in eliminating passwords and making authentication more reliable and expedient for the client. To activate voice recognition, a customer must record a statement that needs to be said aloud when logging in. Consumers like it because they’re recognized more quickly, and they don’t need to answer additional security questions. Businesses like it because tech support fields fewer calls for help. However, while banks claim that voice authentication is more secure than fingerprint reading, there are some concerns about the rapid increase in such modern technologies. Voice biometrics are accepted on the theory that each person has an inimitable voice, but the current research is still based on a relatively small sample. In addition, it’s still unsure how background noise may restrict the attributes of voice biometrics. Other institutions employ facial recognition technology to authenticate customers, when granting access to mobile banking apps. To set up facial recognition, the bank takes a picture of the customer as part of the onboarding process, and that picture is compared to the picture taken with the mobile device’s camera when someone tries to sign in on the device. Iris recognition is also common. With this technology, the device’s camera captures an image of the person’s eyes and analyzes the unique patterns inside the ring-shaped area that surrounds the pupil. Dual-factor authentication can combine facial and iris recognition by also monitoring blinks and eye movement. This additional layer of security helps counter fraud, because a video of a user wouldn’t be able to blink at the right moments. Fingerprint recognition is the other main biometric authentication option available. Fingerprint recognition has been around longer and is the most common means of authentication that’s used in the majority of digital devices, partly because it’s inexpensive to implement. Customers can be given the option to log in to an app using their preferred method — voice, face, or fingerprint — or they can opt out of biometrics and enter a PIN or password. Apart from these biometric options, another approach to multifactor authentication is the use of device identification, where an encrypted token is sent from the device to the institution, which is then matched against the ID of the device registered at the time of enrollment. Voice technology Voice technology has become common in the home, with consumers now able to talk to smart fridges, thermostats, vehicles, and many other devices. Voice assistants such as Alexa, Google Home, and Siri have also changed the way people get information using mobile devices and home management systems. People are becoming increasingly comfortable talking to computers rather than humans to get things done. Voice technology is expected to soon transform the finance sector as well. Gartner Research has suggested that AI bots will control 85 percent of customer service interactions in the near future. Many banks are looking into using voice authentication technology alongside voice-controlled virtual assistants. In such a system, consumers would be able to make a payment by talking to their smartphone app. The app would not only authenticate users by their voice but would also follow their orders to make the payment. As machine intelligence becomes better at voice recognition and conversation, businesses are applying it in many different forms, from biometric security to helpful AI chat bots. While past technological limitations perhaps delayed consumer acceptance of these technologies, radical breakthroughs introduced over the past five years have made widespread adoption more achievable. Voice technology usage is certain to increase in the next several years, further enriching customer experiences with digital devices. Voice recognition will become an integral part of daily transactions by bridging the gap between human and machine conversations. Artificial intelligence Artificial intelligence (AI) is an overall term referring to a group of computing technologies and methods to enable computers to make adaptable rational decisions in response to often unpredictable conditions. The elements of AI include natural language processing (NLP), machine learning (ML), intelligent agents, and rational decision-making. The process involves developing systems that can perform a range of basic tasks better and more efficiently that have traditionally been done by humans. AI is developing at an unprecedented rate due to developments in big data and cloud computing technologies, both of which make it easier to store vast amounts of data, and through the benefit of accessing elastic computing power. ML is effectively a subcomponent of AI but is also its natural ally. Whereas AI involves training a machine to learn from a large amount of ingested structured data using algorithms, ML then adapts its program pattern based on what it learns. For example, ML plays a major role in tools that companies use to analyze data or identify intelligent activities and their applications for organizations and management. ML is therefore one of the most common and effective approaches to achieving AI. However, many challenges remain to complete and maintain a successful implementation. Some of these include data management (such as accessing data from unrelated sources into a common data lake), IT infrastructure, and employing the essential human talent to deploy the technology as the complexity of these techniques has noticeably increased. In addition, the scale of applications across different client segments has seen considerable progress. Initially, machine learning was primarily used to make credit decisions in retail portfolios based on the structured data that financial institutions already had on their retail clients. Nowadays this analysis is being extended to larger corporate and wholesale sectors, where the structured data is being combined with multiple sources of unstructured data where natural language processing can be employed, including news feeds and internal and external supply-chain data. To achieve further advancements, data sets must be unified across institutions to allow more wide-ranging decisions to be made.

Article / Updated 09-06-2020

To buy or to build new FinTech technology is a thorny issue not without its adamant stakeholders and points of view. However, the mystery behind the problem can be resolved by asking some key questions about your situation, which we address in this article. Whichever choice you make, success is driven by thorough planning and clear communication. Is this functionality core to your business? Working with a FinTech company enables an organization to focus on mission-critical operations and outsource the rest. Whenever a company contemplates rolling out new technologies or functionalities, the first question to be asked is whether the new initiative is core to the business. If it isn’t, then engaging with third-party FinTech sources is nearly always the best way forward. Put your development dollars into the creation of code that provides your business market differentiators. If it isn’t core to your financial objectives, you’re stealing money from other areas of the company that will generate business. Even if you have the greatest development team, if what they’re developing is peripheral to their area of expertise, the net effect is that the software will rapidly degrade and become obsolete over time. Identifying what is core to your business is key to your success. Is the application unique? Don’t waste time or money on building what already exists. It makes no sense, either financially or operationally, for a company to build standard applications like customer relationship management (CRM) systems, human resources (HR) and payroll, time management systems, licensing applications, and so on. On the other hand, if the application you want is unique and original, you won’t find it on a third-party vendor’s product list. To get the features and capabilities you want, you may have to either build it yourself or start with something generic and modify it to fit your use case. The latter is often your best bet; it’s a much less daunting proposition to modify an existing application than to start from scratch. Finding applications that are extensible, that are used for many operations, or that integrate easily with other applications and can share databases is a real positive for a rapidly expanding company. Such an application can grow with the needs of the organization while requiring less specialized support. If you choose to go the third-party modification route, you need to make sure that it can be done contractually and that the core third-party application will continue to be supported and updated over time. A thorough review of the application programming interfaces (APIs) available for the product is critical. Which approach is more cost-effective? Building or buying: Which represents the best value? It’s not a simple question to answer, because of all the auxiliary costs involved in both building and buying. On the surface, the question seems like a no-brainer. Buying is cheaper than building, by tenfold. In other words, it costs ten times more to build a system than it does to buy an equivalent system. The maintenance costs are higher for house-built systems, too — 40 to 60 percent more over seven years than the same large, complex, modified vendor model. This is mainly due to economies of scale because a vendor can build a system once and then sell it to many customers, whereas if you build a system yourself, you are its only customer. On the other hand, buying carries its own cost burden, including costs specific to the deployment, both before and after, and annual fees, both maintenance and support, over the life of the contract. With that said, one of the most compelling arguments for buying is that you don’t have to deal with legacy systems, and the technology that’s purchased is constantly being rejuvenated over time. Buying software means paying upfront for the licensing and then (usually) paying again each year for support. License fees can be not only for the software but also any peripherals that are needed to support the software. Look at the projected costs of a live contract over seven years to determine the all-in costs of a purchase versus the all-in costs of an in-house development. You also need to reflect on the cost of deploying the software. Vendors will supply estimates. Be sure to tack on 10 percent to their estimates for hidden and internal costs. Should this application be built? These are the main decision points in deciding whether to build an application: The nature of the application: If it’s unique and/or critical to your core business, build it. If neither are true, buy it. The need to control the nature of the application: In-house building means you have more control and privacy. Privacy can be an issue if it’s important that the code not be shared with other organizations. The cost to build, maintain, and support it: Buying is nearly always cheaper, as we explain in the previous section. The risks involved in the development and maintenance: If you can’t afford for the system to go down, or if you don’t have the in-house staff to support it, you should buy. (More on risks is in the next section.) The availability of robust Software as a Service (SaaS) offerings has lately shifted the balance in favor of buying or subscribing for many organizations. SaaS has substantially altered the need for organizations to own, build, or maintain generic software. SaaS is generally rented on a subscription basis. It’s offered in the cloud, which makes it ubiquitous, and it scales based on user and compute requirements. The vendor provides all support, maintenance, and automated upgrades. This model is particularly appealing to small and start-up organizations. Everything is a trade-off. Within the build versus buy discussion, the amount of control you have is inversely proportional to the cost. Buying the product is less expensive than building it, but you have less control over the direction, distribution, focus, and support of a third-party licensed product than you do over a unique in-house project. What are the risks of building versus buying? It can be difficult to determine the risk level associated with a build versus buy strategy because there are so many potential risks and each one has its own uncertainties: If you build, the time to delivery is your highest risk. Proper project management can help mitigate the risk of failed delivery dates. Schedule slippage is less of an issue when buying because the software is already created and needs only to be integrated with your systems. When buying, the lack of access to source code can be a risk. You must rely on the vendor to address concerns, fix bugs in a timely manner, and develop new functionality in response to your requests. If the vendor doesn’t meet your support needs, you may find yourself stuck with them anyway because of your contract, or because it would be too expensive to change to a different vendor. Due to personal information retention and privacy laws, and country-specific regulatory controls, data management and visibility are also mounting concerns. If you allow a third-party vendor to store and manage your data, it’s important to choose a vendor that will keep you well informed about what’s happening with your data and what security risks their network may be facing. If you manage your data in-house, you must be responsible for adhering to all regulations yourself and bearing the administrative costs of that. When does open source make sense? You can reap the benefits of a vendor system while avoiding some of the liabilities by incorporating open source applications with either vendor-supplied or in-house built software. With open source, you’re getting the reach of a user base that far exceeds your own specific group. The software is tested in ways your team would not. Open source is free to acquire but not completely free to use because of the associated costs, like integration, support, and maintenance. Because support and maintenance costs can be significant, it’s imperative that the open source project you select is vetted and mature and has an active user group and contributors. Open source also mitigates the issue of some elements of control. Your team can develop custom work for critical functionality not currently in the open source package. It can also release updates in an automated fashion, taking advantage of the changes noncompany developers have made. By always contributing new code back to the project, the user company is assured of backward compatibility and shorter update cycles. Unlike vendor code, open source code isn’t a black box. It utilizes the more flexible newer development processes like microservices and is cloud-enabled. The open source community is robust and should be utilized when doing due diligence on any project you’re entertaining. Here are some sites you can use to assess a project: Bitbucket Tigris SourceForge OSDN Freecode FossHub GitHub LaunchPad Open Source Software Directory You must source the discussion boards before selecting any open source project. When you have finally narrowed your selection, the following list should be used to determine which is your most robust option: Does it have a large user base? Does it have a good reputation? Is it interoperable? Does it require specialized skill to use or maintain? If so, this could be costly. Does it have sufficient, well-written documentation? Does it have a good support network? The support network includes a community as well as paid support options. How often has the code been updated since its inception? What is its most recent update? Is the project site well trafficked and well maintained? Is the open source license associated with the product clearly defined? Is there any larger group or company supporting the development of the project? Frequency of updates to the code, longevity of the project, good documentation, and a large user and support group are clear indicators of a successful open source project. When does building make sense? If any of the following are critical to the organization’s success, building is your best bet: Does the software have specialized functionality that only your company needs? Does the software need to be customizable? On the fly? Are data control, security, and privacy a must? Is the output or the workflow specific to your company’s use case? Have you searched and not found software that solves your critical problem? Does your company have the IT and developer resources to create and maintain the software? The benefits of building can be summed up in one word: control. With building, you own the code and the functionality being built. The potential liabilities of building are just as apparent. Your company may not have the inside expertise to accomplish the build, and you won’t know until it’s completed whether it fulfills all the objectives. In addition, because the software is unique to your company, it will require specialized user training. How can we accelerate a build? One way to accelerate a build is to create a hybrid system that combines third-party components with some internal development. Some examples of the type of systems that lend themselves to this collaboration are Customer relationship management (CRM) systems Content management systems (CMS) Business process automation systems E-commerce software solution Business portals As an example, Salesforce.com is perhaps one of the best SaaS software offerings for customizing out-of-the-box functionality. It enables customers to build their own custom processes or to hire third-party developers to develop applets that provide greater functionality. Salesforce.com retains the responsibility for the infrastructure it provides while making tools available for the company and the end user to customize. For such collaboration to be successful, the vendor must assemble a very exacting set of requirements, objectives, and deliverables. An expert project manager is key to staying on schedule, along with having a concrete statement of work. Another way to speed development is to embrace DevOps, which is a new discipline that automates standardized operations and processes used by development and quality assurance teams. It’s an outgrowth of the small cross-functional teams used in open source, microservices, and Agile-like development. DevOps is for automating processes in a controlled way, developing continuous integration and deployment environments. Automation and continuous integration make it easier for teams from different organizations and different locations to work together in real time. Application programming interfaces (APIs) in third-party software make it easier and faster to deploy third-party code. They enable internal developers to collaborate with third-party vendors and open source projects easily. In-house developers can utilize APIs to build layers of functionality on top of a third-party black box or to make their software available to a third party without revealing any of the corporation’s secrets. When does buying make sense? Just as there are clear indicators for when building makes sense, there are also indicators for when it makes more sense to buy. Those reasons are the inverse of why you build. One of the most critical questions to ask is, “How soon do you need this functionality?” If your answer is “now” or “very soon,” then buying is your solution. You should also buy if one or more of these things are true: The functionality is ubiquitous and used across companies. It isn’t core functionality required to drive the company’s success. It’s outside the company’s area of competence. It isn’t cost-effective to build or maintain. Development of it deflects labor that could be working on more core functionality and thereby takes money away from the company. Applications already exist in the marketplace that can be deployed out of the box, that are mature and bug-free, and that have a support and user network. The benefits and drawbacks of buying should be apparent when you review your spec and scope document. Some reasons for buying include economies of scale, focused domain expertise, rapid deployment, ongoing maintenance and support, complete QA and documentation, wide user groups and external support, and known predictable costs. Just like building, buying has its own set of liabilities. With buying, you own nothing and are completely dependent on the supplier. You have no control over data integrity. You can’t dictate the levels of security, and you can’t drive the areas of new functionality. And if the vendor goes out of business, you may lose your software support and be unable to get updates. If the application you’re selecting is important to the day-to-day operation or to the company’s bottom line, you may want to build an escrow component into the terms of the contract. There are also some hidden risks involved in buying. Consider these possibilities, for example: The request for proposal (RFP) process could be flawed and the product may not match the company’s needs. If the application is being integrated into some other system, there may be compatibility issues. It may take more time to deploy than anticipated. How do we select a vendor and a product? When you’re shopping for software to buy, the vendor is just as important as the product itself. Make sure that the vendor you choose Has economies of scale. Provides support and training. Has a focused skill set that drives development and functionality of the application. Has a proven track record for supplying needed functionality. Has designed the software to be flexible and interoperable. Offers regular reviews and upgrades, making the software future-proof. Many vendors offer multiple software products to choose from. Before you finalize your buying decision, you should be thoroughly familiar with the software, its capabilities, and any potential drawbacks, including any areas where the vendor doesn’t provide strong support. Here’s a partial list of questions that you should ask about the software and vendor you’re considering: How often is the software updated? What does the update process look like? Is there free software training? If not, what type of training and cost is available? What is the level of support during deployment? After deployment? What type of reports are available out of the box? What other software does this system interface with? What are the hardware requirements? What is the cloud capability? What is the mobile capability? How is data integration carried out? What is your road map for the product’s future functionality? How far out does the road map go? What is your security model? Have you ever had a breach? What certifications does your system and team hold? Do you have a Service Organization Controls (SOC) report? What is your disaster recovery plan? Has it been tested? What is your data management plan, and what is your data disposal process?