This Security Policies document has been produced by Crowd Valley senior management and the Crowd Valley Security Committee.

The document comprises eight main sections:

• Section 2 provides an overview of Crowd Valley’s general approach towards security and lists the documents and policies that comprise the company’s complete security policy.
• Section 3 provides a Systems Diagram of the Crowd Valley infrastructure.
• Section 4 provides a Network Diagram of the Crowd Valley infrastructure.
• Section 5 describes Crowd Valley’s system development and maintenance processes.
• Section 6 describes the company’s Information Security Policy.
• Section 7 lists the company’s business continuity management procedures.

Crowd Valley customers can re-use these policies whilst applying for regulatory authorization. They must be taken whole and without editing.

Please contact security@crowdvalley.com for any further information or to request a hard copy of the information contained on this page.

2.1.1 General Principles

Crowd Valley’s technology products and APIs have been developed with the goal of providing a modern, robust and fit-for-purpose back-end infrastructure for the new digital finance market. The company’s APIs tie together the best and most innovative online services from around the world in risk, compliance, finance, identity, asset management, and payments. By working alongside the leading fintech service providers globally we aim to provide a new infrastructure for the next generation of financial services companies.

Working with such partners also allows us to benefit from their security protocols, for instance payments services firms that can provide complete PCI compliance for customers using their systems. Our team has embraced working online, remotely, and globally from Day 1. The protection of digital assets such as customer data has been core to our operations since the very start.

We understand that information security and especially end user data are of critical importance to our customers and we aim to go beyond what would be considered industry standard for the kind of data that we hold.

The information security policies below are developed from the bottom up to ensure that every policy is workable and has the full co-operation of the team, whilst having the full support of the company’s senior management.

We take non-compliance extremely seriously and we take immediate action against any individuals who knowingly contravene these policies.

2.1.2 Roles and Responsibilities

Crowd Valley’s policies and reviews are conducted by a Security Steering Group, which comprises the company’s CEO, CTO, Chief Legal Counsel and Head of Engineering.

2.1.3 Approach to holding data

Crowd Valley aims not to hold data that are sensitive, such as credit card data or other information that could be used to forge a user’s identity. The data model and API have been designed so that only the user him/herself and the site administrators have access to personal data, such as registered address, date of birth, place of birth; when accessing data about other users, the data returned is very restricted, for example returning the more generic ‘location’ attribute rather than the user’s actual address.

Where third-party services are involved, Crowd Valley only stores ‘tokens’ or user identification numbers for those services; we never store credit card details.

2.1.4 Approach to aggregating data

Crowd Valley customers benefit from each other’s efforts to identify and eliminate fraudulent activity or efforts by unscrupulous users to launder money. Crowd Valley administrators are able to look across customers’ databases on an anonymous and aggregated basis, without being able to identify individuals, such that we can receive alerts if a user with a certain email has raised a KYC/AML Exception on several different Crowd Valley customer platforms. In this way we are able to complement the KYC/AML checks performed by our partners to help our customers to reduce the chances of accepting fake or fraudulent users onto their platforms.

Crowd Valley’s Security Committee has developed this document according to the following process.

2.2.1 Define the objective of the company’s overall Security Policy

The starting point for creating this document was to identify its objective. The current objectives of the company’s Security Policy are:

• to protect the organization's business information and any client or customer information within its custody or safekeeping by safeguarding its confidentiality, integrity and availability;
• to establish safeguards to protect the organization's information resources from theft, abuse, misuse and any form of damage;
• to encourage management and staff to maintain an appropriate level of awareness, knowledge and skill to allow them to minimise the occurrence and criticality of Information Security incidents;
• to ensure that the organization is able to continue its commercial activities in the event of significant Information Security incidents; and
• to prepare for application to International Standards ISO 27001.

2.2.2 Identify the full scope of activities

The Crowd Valley Security Committee has identified the following policies and procedures that comprise the company’s Security Policy.

• Web Application Security policy
• Product Updates policy
• Organization Security policy
• Partner Security policy
• Personnel Security policy
• Physical and Environment Security policy
• Digital Access Control policy
• Communications policy
• Backup and Disaster Recovery policy

2.2.3 Define the goal of each individual policy or procedure

Once the full scope of activities has been identified, the company determines the aim of each individual policy and procedure. The aims of each policy are defined in the relevant sections below.

2.2.4 Describe a step-by-step process that would achieve the goal of each policy

Having defined the goal of a particular policy or procedure, we then write out a step-by-step process that would enforce or enable the goal. These processes are described in the relevant sections below.

2.2.5 Conduct a gap analysis between the required process and current practise

We describe the current practise and identify any gaps between current practise and the ideal step-by-step process. If such gaps exist, we create an action plan to bring current practise in line with the required process. Each action plan is labelled as high criticality, medium criticality or low criticality.

2.2.6 Review the results of each action plan

The Crowd Valley Security Committee reviews progress against the action plans quarterly for medium or low criticality action plans, or monthly for high- criticality action plans. If the action plans have been effective and the policy is being implemented then the plan is marked as complete. Otherwise, it may be given an increased criticality, or an alternative action plan may be suggested.

2.2.7 Review the overall Security Policy

The full policy, including the results of any incidents and the subsequent implementations – successful or otherwise – of the security policies and procedures, is reviewed semi-annually by the Security Steering Committee along with independent certified security assessors.

All Information Security incidents are recorded in company records. All findings are considered confidential and are to be distributed to persons on a “need to know” basis. Distribution of any findings outside of Crowd Valley is strictly prohibited unless approved by the Security Committee.

2.3.1 Regulatory Compliance

Crowd Valley proactively seeks to develop industry best practises itself and to encourage its customers to do the same, by creating knowledge materials and standardizing information security processes.

Being in a highly regulated sector, we work closely with financial regulators around the world. We grant those regulators access to customers’ data only on receipt of a competent and formal legal request, as required by law and as outlined by our written agreements, such as our terms and conditions, privacy policy or others agreements in effect from time to time.

2.3.2 Ethics

The company considers its business processes around compliance, confidentiality, transparency, neutrality and professionalism imperative to its success and at the core of that is its view on maintaining fully and absolutely ethical operations at all times. We believe this is absolutely integral to the company’s brand and that which we promote to our clients around the world.

This includes behaving in the best long-term interests of the company, which we believe include acting without any prejudice or discrimination, and in the best interests of our clients, our partners and the global fintech market at large. Internally, we believe honesty is the quickest way to achieve the best result, and anything short of that is an unacceptable waste of everyone’s time.

Ever since we set out in the global market as entrepreneurs in 2009, we have believed that maintaining the highest quality of operations will benefit the company most in the long term.

2.3.3 Special interest groups

We believe that our customers will benefit from a strong ecosystem in and around the new digital finance market, and accordingly we welcome discussions around information security and data protection with our development partners, service provider partners and other interested stakeholders.

We aim to keep those groups informed about any updates or changes to our core technology infrastructure, especially as it applies to their customers, and equally we develop relationships with the same groups so that they will keep us informed of changes to their business.

Where possible, we require all third-party service providers to keep us informed of any service downtime, which might affect our customers’ platform operations, and to contact us with sufficient notice in the event that their products or services change materially.

Crowd Valley customers are required to complete the company’s own KYC form so that we have on record all the information that we may be required to provide to regulators in the event that a customer undertakes fraudulent activity or money laundering or is investigated of or relating to such activity.

We require all customers to renew this form on an annual basis and to keep us updated should any significant change be introduced to their business practises.

We also require our customers to ensure that API keys and API secret codes, which are used for authentication with Crowd Valley APIs, be kept secret, and if they suspect that anyone else has gained illegitimate access to these keys then they must report it immediately and request new credentials.

Customer front-end sites are required to use valid SSL certificates so that all data exchange can be performed using the secure HTTPS protocol.

In addition, the Crowd Valley API should be used in the way that it was designed. For instance, it is possible, although discouraged in the strongest possible terms, to store credit card numbers against a User’s database record, to save unencrypted passwords in custom fields, or to hold highly sensitive information such as passport scans in unencrypted online storage facilities. Customers found following such practises may have their agreements terminated by Crowd Valley in order to protect their end users. Whilst we strongly encourage customers to follow these practises, we cannot prevent all possible malicious behaviour, and it is ultimately our customers’ responsibility to ensure that their own front-end applications follow industry standards.

This section describes the scope of the Crowd Valley infrastructure and product suite, and the technical relationships between each element.

There are four constituent parts to the core Crowd Valley infrastructure. It is a ‘LEMP’ stack (Linux, Nginx, MySQL and PHP) that includes the Crowd Valley APIs, the back-end database, the administrator portal, and third-party services.

Crowd Valley APIs

The Crowd Valley suite of APIs is built using back-end scripting programming languages and frameworks such as PHP and Python.

Back-End Database

Crowd Valley back-end databases, which store user-generated content and system meta-data, are MySQL databases hosted with Amazon Web Services.

Administrator Portal

Crowd Valley’s customers also have access to a back-end administrator portal, which allows, for example: managing their user bases and tracking investor KYC and AML statuses; managing a pipeline of deals before, during and after investment; communicating with investors; closing and settling investments; and managing third-party services. The Portal is accessed through an independent site, completely separated from the front-end application(s). It is hosted and maintained by Crowd Valley.

Third-Party Service Providers

Crowd Valley has integrated with dozens of third-party service providers for ancillary services that support or in some way enable the investment processes that take place online on top of the Crowd Valley infrastructure.

Such ancillary services include payment processors, ID verification checks, global PEPs and sanctions list checks, online escrow services, credit scoring, beneficial owner and company background checks, market data feeds, electronic signatures, and research or due diligence reports.

On top of the core infrastructure, Crowd Valley customers also operate one or more of their own user front-end applications. The API-centered structure makes it possible to build any number of custom applications or networks of services around Crowd Valley’s customers’ investment services, accessing different functionality separately or in full, all protected and secured through the customer’s admin portal.

The user front-end applications are the websites or mobile applications that end users would see. User front-ends can be based on existing templates or they can be unique user interfaces built for a completely custom user experience. Front- end platforms can be built in any programming language or framework, including mobile technologies.

User front-ends are hosted and maintained by Crowd Valley’s customers themselves or Crowd Valley partners working on behalf of those customers.

This section describes the network connectivity between elements of the Crowd Valley infrastructure.

Crowd Valley makes use of Amazon Web Services’ industry-leading infrastructure such as EC2 server instances and S3 storage facilities. The servers are held in AWS regions in Ireland (for the majority of customers including all in the EU and US) and Singapore (for selected South-East Asian customers).

The purpose of this policy is to define web application security assessments within Crowd Valley. Web application assessments are performed to identify potential or realized weaknesses as a result of inadvertent misconfiguration, weak authentication, insufficient error handling, or sensitive information leakage.

Crowd Valley web applications and APIs are subject to security assessments based on the following criteria:

5.2.1 New or Major Application Release

Major releases are subject to a complete assessment prior to approval of the change control documentation and/or release into the live environment. These releases also require complete updates to documentation and marketing materials and, where appropriate, formal communications to developers and partners using the Crowd Valley infrastructure, including details of any depreciated or unsupported functions or services.

Major releases are indicated in product documentation by increasing the first number in the semantic versioning, e.g., a progression from v1.2.3 to v2.0.0

5.2.2 New Third Party Service Integration

Third party service integrations are required to pass a complete assessment after which they will be bound to standard policy requirements. Third Party service releases are indicated in product documentation by increasing the second number in the semantic versioning, e.g., a progression from v1.2.3 to v1.3.0

5.2.3 Patch Releases

Patch releases, including hotfixes or emergency releases, are required to follow an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.

Patch releases are indicated in product documentation by increasing the third number in the semantic versioning, e.g., a progression from v1.2.3 to v1.2.4

5.2.4 Server Software Installation

Requests to install software on Crowd Valley servers must first be approved by the Head of Engineering and CTO and then recorded in internal company records.

Software must be selected appropriately, ensuring that it will not affect the functioning of other applications or packages. As required, the company will obtain and track the licenses, test new software for conflict and compatibility, and perform the installation. Installations must be conducted on test or sandbox servers first before being used in a live environment.

All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the OWASP Risk Rating Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.

5.3.1 High

Any high-risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment. Applications with high-risk issues are subject to being taken off-line or denied release into the live environment.

5.3.2 Medium

Medium-risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly. Applications with medium-risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues should be fixed in a patch release unless other mitigation strategies will limit exposure.

5.3.3 Low

Low-risk issues should be reviewed to determine what is required to correct the issue and scheduled accordingly.

The following security assessment levels are used by the Crowd Valley Security Committee or other designated organization that will be performing the assessments.

5.4.1 Complete

A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide. A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.

5.4.2 Quick

A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.

5.4.3 Targeted

A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.

5.4.4 Tools

The current approved web application security assessment tools that are used for web security testing are:

• Nmap Port Scan
• OpenV AS Scan
• SQLmap Injection Test
• SSL security check
• OWASP Top Ten Project

Other tools and/or techniques may be used depending upon what is found in the default assessment and the need to determine validity and risk are subject to the discretion of the Security Committee.

Before every product release, including new major applications or features, new third-party service integrations, and new patch updates, the full API code stack is tested against a unit test script that includes exhaustive functional tests of every documented API feature.

The unit test script includes several thousand tests that are run automatically against the internal development version of Crowd Valley's API.

Releases of any size are thereby prevented from being pushed to Crowd Valley's sandbox or live environments if unit tests do not pass as expected.

Crowd Valley's Back Office admin application is also tested manually following a standardized test script in advance of any Back Office sandbox release.

This process is followed to ensure that Crowd Valley's customers' critical process workflows are not compromised by any accidental bugs that may be introduced during a normal release cycle, so that customers and their development teams can rely on their back-end processes.

Crowd Valley releases regular updates to its core API and Back Office application in line with its roadmap and customer or partner requests.

Each product release is pushed first to the sandbox environment no less than 5 working days before the same release is pushed to live environments, to ensure that developers have the opportunity to test their applications in a sandbox environment before the live version is updated.

Crowd Valley sends out a Release Notice newsletter for every major and minor sandbox release to give a full list of all updates that were made as part of the release. The newsletter also confirms when the release will be made to the live environment.

Full details of all Crowd Valley product releases are also documented on this site at www.crowdvalley.com/releases

Developers are encouraged to get in touch with Crowd Valley support if they are unsure about any new feature or bugfix during the period where the release has been deployed to sandbox and not yet to the live environment.

Due to changes in regulations, policy, third-party service provision, or customer requirements, certain features of the API will be deprecated and ultimately removed from time to time.

Depreciated features are marked as such on the API documentation page at www.crowdvalley.com/api, which also shows the release number at which the feature was depreciated and the alternative solution.

Feature depreciations will be communicated to developers by a special email newsletter and also as part of the regular Release Notice newsletters that are sent to all registered Crowd Valley developers.

Depreciated features will be supported for at least 6 months after the depreciation has been announced before being removed. During that time, a 'depreciation' indicator is sent as part of the API response for this feature.

At regular intervals up until the time when a depreciated feature is to be removed, reminders are sent to all registered developers by email to ensure that they have ample opportunity to adjust any front-end platform that may still rely on this function.

Information security is the practise of ensuring information is only read, heard, changed, broadcast and otherwise used by people who have the right to do so. It requires a range of skills and knowledge and increases in importance as our use of and reliance upon information grows.

This policy sets out Crowd Valley’s definition of, commitment to and requirements for information security. It specifies the need for security controls to be implemented according to the needs of the company, defines responsibilities for information security and refers to more specific policy documents. The information security infrastructure comprises the resources and mechanisms the organization will use to establish, implement, document and maintain this policy.

This section comprises the following sections, which represent the full list of policies and procedures related to Information Security.

• Organization security – which members of the organization have access to data and what responsibilities apply to those members?
• Crowd Valley Partners – how does Crowd Valley ensure that development partners do not get direct access to customers’ data even when they are developing those customers’ front-end platforms?
• Crowd Valley Personnel – how does Crowd Valley onboard and terminate employees who may have access to that data?
• Physical access controls – what physical assets do we own and how do we control access to them?
• Digital access controls – what digital assets do we own and how do we control access to them?
• Sharing information controls – how do we control the distribution of sensitive data by those who have obtained those data, either validly or otherwise?

For information security purposes, Crowd Valley has three categories of employee:

6.2.1 Security Committee Members

The Security Committee comprises the company’s CEO, CTO, Legal Counsel and Head of Engineering.

Members of the committee have direct access to customers’ databases and therefore, in principle, are able to see any data provided by customers’ end users.

Members are also able to change data directly in the database. This level of access has been configured in order to satisfy any legal requirements the company may have to retrieve or validate certain data provided by end users. All access requests and database changes are logged and visible to customers’ admin teams.

Such data must not be copied, written down or distributed, and doing so would constitute a severe breach of this policy.

6.2.2 Customer Support

Crowd Valley’s team includes various customer support agents who may be contacted by customers with support requests. Customers are able to grant access to their admin portal on a temporary basis so that the Crowd Valley agent can log in and assess the support request.

Whilst making the assessment, the agent will have access to live customer data and will be able to make changes to that data, just in the same way as the customer’s own admin team can.

Such data must not be copied, written down or distributed, and doing so would constitute a severe breach of this policy.

All access requests and database changes are logged and visible to customers’ admin teams. The support team’s access can then be revoked as soon as the request has been handled.

6.2.3 Other

The remainder of the Crowd Valley team – whether developers, testers, engineers, or those in sales, marketing, operations, finance or business development roles – have no access to live customer sites or data.

The front-end platforms that Crowd Valley customers operate are often built by third-party development agencies, since Crowd Valley itself does not build front- end applications.

To support the sector, Crowd Valley has invested in training schemes and support materials to help freelance developers and agencies learn how to build on top of the company’s APIs.

The level of access to data given to the partner firm is completely in the hands of the end customer, up to a maximum level of access, which is the same level as the customer themselves have to data.

Partners do not have direct access to the databases – either when testing or when in live use – so all requests to access data must be signed and authenticated through Crowd Valley APIs, which in turn enforce controls by limiting the scope of data that can be retrieved. For more information on this process please refer to the section below on Digital Asset Control.

Crowd Valley employs several core concepts in its recruiting and team building process, including a strong initial filter, high hurdle to gain real responsibility, meritocratic performance based vetting of candidates and diligence.

6.4.1 Central importance in the organization

Team building and recruiting, including its impact on the company culture, is seen as such a core part of the company’s long term that Crowd Valley’s CEO personally interviews each and every candidate for a position. This allows for a dual function, for one to be able to ensure quality of new applications, and for the other to be able to strongly display and communicate the core values of the company first hand to new people, whether they join the company or not.

6.4.2 Strong initial filter

Crowd Valley has screened thousands of applications for its positions and based on this experience, has implemented a filter to identify suitable candidates, and even more so, deterred those who it believes are not suitable for consideration in the company, its working culture and values. This proprietary process involves requiring a high initial commitment, identifying problem solving abilities and risk tolerance, as well as knowledge of relevant areas of the market, such as technology, compliance, risk, brokerage, or other pertinent knowledge. The company also employs background checks, including social media accounts such as LinkedIn and Twitter, bad actor checks, financial intermediary reports such as FINRAs broker check and other sources to which it may gain access.

6.4.3 High hurdle to gain real responsibility and access

Crowd Valley values meritocracy highly. This means that any new person brought into the team needs to prove themselves with real work starting from the ground up, and to gain the trust of their peers, before being considered for any further responsibility. This means that outside candidates are never given significant responsibility or access to critical data or information, before truly proving themselves, which typically takes at least six months. This includes concepts like never recruiting managers from the outside directly, but rather having everyone start from the ground up internally to truly vet that they are committed to the values of the company as well as guarantee they gain the trust and respect of their peers.

6.4.4 Meritocratic performance based data collection and team building

Crowd Valley and its management have strong track records of building teams. As part of this collective expertise, the company has implemented processes that are honest and pragmatic, and based on verifiable data on performance. This means that candidates, both ahead of being recruited and after initial positions, are challenged with diverse problems, assignments and responsibilities, to assess how they respond and are able to manage different situations. This includes tasking people with responsibilities outside their comfort zones or training, as well as tracking both the tangible results as well as the behavior when things do not go their way. No one is perfect, and what Crowd Valley particularly looks for is an honest and humble approach and willing to learn and develop along with the company and market.

6.4.5 Constant learning and development

As part of its core values of operating in a new market, Crowd Valley values learning and personal development highly. This comes from a core belief that the financial services market is undergoing a fundamental change and this investment in how it will work in the future, is innately valuable and applicable in the long term. With that notion a core value in the company, everyone is pushed to challenge themselves, rotate responsibilities, build out their competencies and capabilities, as well as keep challenging the company to do so as well.

6.4.6 Correcting behaviour and ensuring quality

Crowd Valley values brutal honesty internally and when something is seen as against the company’s core interests or out of place, direct steps are taken. Mostly this involves a direct and frank conversation with colleagues and figuring out how to address any issues, which typically leads to the full resolution of the original issue and a plan with monitoring on how to avoid such an issue in the future.

However, there are a series of unacceptable actions that will result in immediate termination of contract, such as unethical behaviour, behaviour against the interests of the company, political behaviour and violation of other explicit agreements in place.

6.4.7 Termination

In the case of termination of services, all access rights are revoked and data transferred, a Termination Certificate is signed stating existing obligations and returns of material. This process is handled swiftly and directly, with the aim of ensuring that the person terminated has in his or her best interest to further the long-term success of the company.

6.5.1 Approach to Physical Assets

Crowd Valley does not own physical servers, and the company’s own physical offices are only used for business operations not warehousing or data storage. Therefore, physical access to the servers on which customers’ data are held is not possible for Crowd Valley employees or partners. All physical servers are owned and hosted by Amazon Web Services.

The physical assets for holding and processing information and information processing are, accordingly, solely the physical servers hosted by Amazon Web Services, which hold customer databases, database backups, and the code required to run the web applications or API products provided by Crowd Valley.

Crowd Valley will grant reasonable access to its physical offices upon receipt of a competent and formal legal request, as required by law and as outlined by our written agreements, such as our terms and conditions, privacy policy or others agreements in effect from time to time.

6.5.2 Server security policy

All internal servers deployed at Crowd Valley must be signed off by the Head of Engineering and CTO. The company maintains approved server configuration guides, based on business needs and approved by the Security Committee.

Servers must be registered within the company’s server management system, which is part of the Amazon Web Services infrastructure.

For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic as required by the Head of Engineering.

Operating System configuration should be in accordance with approved guidelines. Services and applications that will not be used must be disabled where practical. Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible.

The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.

6.5.3 Remote access policy

Secure remote access is strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases. Authorized users are limited to those members of the Crowd Valley Security Committee. Members must protect their login and password, even from family members.

While connecting remotely to Crowd Valley’s physical assets, members must ensure that the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control.

Where applicable, two-factor authentication is required to connect to live Crowd Valley global admin products, before members are able to access any live customer data.

6.5.4 Remote tools policy

Access to the live database for any user through any other third-party tool must be connected through the relevant Crowd Valley API. Direct access to the database is forbidden.

Remote desktop software, also known as remote access tools, provide a way for computer users and support staff alike to share screens, access work computer systems from home, and vice versa. Examples of such software include Skype, LogMeIn, GoToMyPC, etc. These systems should not be used to demonstrate any live network admin sites, super admin sites, or customer front-end sites (except publicly available pages).

All demonstrations should be performed using sandbox or testing sites. Global admin analytics such as anonymous and aggregated data may be permissible in some circumstances with the consent of the Security Committee.

6.5.5 Printing policy

Under no circumstances should live customer data be written down, copied or physically printed.

6.6.1 Digital Assets

The primary digital asset is the company’s codebase, which controls how data can be accessed, created and updated.

The code repository is hosted and managed using GitHub. Administrator access to the code that is used on live sites is restricted to Crowd Valley Security Committee members.

Whilst the code can be downloaded by any Crowd Valley developer given access by the CTO, it cannot be updated on the company’s sandbox without being first screened by an automated test and then being manually tested by a Crowd Valley Project Manager. All code updates are verified on internal development versions and sandbox environments before being updated to live platforms.

Each release is tested according to the system development and maintenance policies described above.

6.6.2 User Types

The Crowd Valley infrastructure defines four types of User:

• Super admin – these users are members of the company’s Security Committee. Super admin users have access to live data across all customers’ databases.
• Global admin – these users are Crowd Valley technical support agents. Global admin users have access to live customer data only when granted permission by a customer on a temporary basis through the Crowd Valley network admin portal. They also have access to aggregated information and analytics through the Crowd Valley global admin portal.
• Network admin – these users are Crowd Valley customers’ own admin teams, i.e., the operators of a platform that runs on top of Crowd Valley’s infrastructure. Network admin users have access to live customer data from their own platform through the Crowd Valley network admin portal.
• End User – these users only have access to their own data and to as much data as may be revealed through the API on a Crowd Valley customer’s front-end application. It is up to the customer to determine how much data can be shown on their front-end, although certain data are restricted by the design of the Crowd Valley API.

6.6.3 Digital authentication

All requests to retrieve data from Crowd Valley customer databases must be sent to the relevant Crowd Valley API using the HTTPS protocol and including a ‘cv_auth’ token, which is used by the API to authenticate the request.

The network name is the unique customer identifier, which determines which database the user is trying to access.

The ‘cv_auth’ token is a system-generated string, which uses five inputs to create a token that can be then be verified by Crowd Valley’s API:

• Network Name, which is used to create the digest string as part of this header;
• API Key, which defines the current application that the user is using to make the request;
• API Secret, which is a random string that is created by Crowd Valley when the API Key is generated;
• Username, which is the email address of the user who is making the request;
• Encrypted Password, which is an encrypted version of the user’s password.

Any request which cannot be authenticated, because any one of the five inputs does not match any other, will receive a ‘401 Unauthorized’ HTTP response and no data will be provided by the API.

6.6.4 Database credentials creation and destruction

All new users including global admin users, network admin users, and end users must be created through the relevant API methods, meaning that every user that is created or revoked is logged against the user who made that request, the application used, and the time.

In addition, Crowd Valley also stores the IP address of all users who make an API request.

Once created, data in the databases are never destroyed, even if users’ accounts are ‘disabled’ or customer data is ‘archived’ and hidden from a Crowd Valley customer’s network admin portal or front-end. Data are maintained in this way in case of future audit or legal requirements.

6.6.5 Password requirements

User passwords are never stored in a world readable or writeable way, and they reside separately from the documents tree of Crowd Valley applications. They are never accessible directly by any web server.

Every user must have unique database credentials. Sharing of credentials between users is not allowed.

Users’ passwords can be reset at any time either manually by an admin user or automatically on a timer, such as every 30 days.

All admin passwords should have the following characteristics:

• Contain at least 12 alphanumeric characters.
• Contain both upper and lower case letters.
• Contain at least one number (for example, 0-9).
• Contain at least one special character (for example,!$%^&*()_+|~- =\{}[]:";'<>?,/).

6.6.6 Information logging

All API requests and responses are logged along with the IP address of the requester.

6.7.1 Email policy

Live database usernames and passwords should never be distributed by email. Temporary passwords are sent out by automated systems and users are required to change them as soon as they log in.

All use of email must be consistent with CV policies and procedures of ethical conduct, safety, compliance with applicable laws and proper business practises.

Crowd Valley email accounts should be used primarily for Crowd Valley business-related purposes; personal communication is permitted on a limited basis, but non-Crowd Valley related commercial uses are prohibited.

Crowd Valley may monitor messages without prior notice. The company is not obliged to monitor email messages.

6.7.2 Recording and copying of data or digital assets

Crowd Valley developers must not distribute copies of any software application to which they have been granted access. Whilst this is difficult to enforce, Crowd Valley benefits from separating the various elements of its infrastructure so that no single developer can have access to all the constituent parts required to replicate the full technology stack. Developers either have access to the API, or the admin applications, or the customer front-end applications, but not all together. Moreover, Crowd Valley developers never have access to live customer data nor live API keys, so they are not able to build other applications that could ever access customer data. Further, customer front-end applications are built by developers without access to the code required to operate the API separately.

Those super admin users who have been granted access to live customer data are forbidden from writing down, copying, taking screenshots, or otherwise distributing customer data from live platform operations.

Backup and Disaster Recovery policies include the plans and procedures for the maintenance of essential business activities during adverse conditions, from coping with major disasters to minor, local issues.

The front line of Crowd Valley’s disaster recovery is the organization’s global distribution and virtualization of all technology systems and data resources: there is no single office and no single physical server whose disabling by natural or other disasters would affect Crowd Valley or its services.

Backup and disaster recovery at Crowd Valley are implemented primarily through our core cloud-based web and data infrastructure at Amazon Web Service (AWS). This flexible cloud computing infrastructure is the same technology used by thousands of innovative companies all around the world. All data and related services on the Crowd Valley platform are protected by virtualization, resource distribution and automated backup and storage on the cloud, as well as by specific schemes to enhance redundancy and durability.

7.2.1 Virtualization and resource distribution

Traditional physical data storage and IT infrastructure is susceptible both to hardware failure and to natural or man-made disasters that could cut power to physical hardware or destroy it. With cloud-based virtualization, there is no single physical machine that can fail or be disabled. Instead, one or more virtual servers (each a program running in parallel on multiple physical machines at once) provide all data and web services. Such virtual servers run on large collections of redundant physical servers, in such a way that the failure of any one or even several physical servers does not cause the failure of any virtual server. Wholesale failure of the entire collection of physical servers (due to a power failure, for example) is extremely rare, because such facilities have their own redundant dedicated power supplies standing by in the event of power failure. Usually, only the physical destruction of a large portion of the server facility would disable the virtual servers hosted there, although there have been rare instances of other problems (such as software malfunction) temporarily disabling cloud-based computing resources en masse.

AWS mitigates even this slight risk by making available multiple availability zones, that is, widely separated geographic regions, over which computing and storage resources can be distributed. For example, redundant data storage services can run simultaneously in each region. In the event of catastrophic failure in one region, all data services would “fail over” to the other region with minimal loss of data. Crowd Valley’s infrastructure platform utilizes availability zones in the United States and the EU for redundant data storage, and also replicates to storage with a second, non-AWS provider. Other zones can be made available in Japan, Singapore, Australia and Brazil for greater assurance or special business compliance or policy requirements.

7.2.2 Automated Backup and Cloud Storage

In the same way that our system’s computing power is provided by a collection of physical machines, our system’s data storage is a virtual disk volume provided by a collection of physical storage devices. Crowd Valley’s systems always keep primary data storage logically separate from secondary server storage, which means that in most cases even a problem that disables the virtual server will not affect the data volume, which can be detached and reattached to a new server. But data volumes do occasionally fail, and we are prepared for that.

AWS provides two levels of assurance for virtual data volumes. First, the volumes themselves are hosted on stable physical systems that are highly redundant, meaning that the failure of a data volume is rare (Amazon estimates the failure rate of such volumes to be between 0.1% and 0.5% annually). Second, all data volumes hosting Crowd Valley infrastructure, including client and transaction data, are regularly backed up to permanent secure cloud storage (Amazon S3). Amazon rates the durability of S3 storage as having an average expected annual loss of 0.000000001% of files; in other words, the chance of a data file on S3 becoming unrecoverable is about 1 in 1 billion.

7.2.3 Disaster Recovery Plan

Crowd Valley’s operations are globally distributed and virtualized, and have been from the company’s inception. Crowd Valley personnel and staff resources reside in multiple cities in multiple countries on multiple continents, including the United States, the United Kingdom, Hong Kong and elsewhere. Operational knowledge is shared through a combination of online services and constant collaboration. Therefore, there is no single point of failure -- no physical structure that can be affected by flood or fire, no physical files that can be lost, no single person uniquely holding critical knowledge.

Nevertheless, we do not rule out the possibility of an incident causing severe and possibly catastrophic failure of part or all of the technology infrastructure we depend on. Because Crowd Valley’s platform runs in a cloud computing environment, most virtual server failures would temporarily increase the latency (delay) an average user experiences while using the platform, and at worst make the platform unavailable for a few minutes. In the rare case of an event causing the outright failure of Crowd Valley’s cloud-based infrastructure, the following steps take place.

1. Crowd Valley personnel are notified within 1 minute of such a failure, and would either restart services or start new virtual server and/or new storage volume instances based on the most recently stored copies (or, if there is a problem with the most recent copy, the most recent usable copy).
2. In the unlikely scenario that AWS global cloud computing infrastructure itself goes down, there would be an interruption of Crowd Valley platform services. However, all data would remain in redundant storage, and would be accessible as soon as AWS became available. Crowd Valley assumes complete failure of Amazon S3 storage (or equivalently, failure of the company or accidental deletion of Crowd Valley accounts) to be very unlikely, but still backs up all platform data on a daily basis to non-Amazon physical storage. In a very worst- case scenario, excepting perhaps a catastrophic internet-wide issue, a day of data could be lost, and it could take several days to restore access to offsite stored data.
3. In the event of complete failure of a data volume for any reason, the volume will be restored from the most recent S3 storage.
4. There is also a slight but nonzero risk posed by accident or illness disabling Crowd Valley personnel. Crowd Valley mitigates this risk by ensuring that there is more than one person at all times who can respond to emergencies to troubleshoot and resolve problems. All team members have open lines of communication to other team members via phone, email and VOIP/IM channels.

7.2.4 Data Protection and Durability

Crowd Valley systems include three kinds of data: 1) files uploaded by users, 2) application data other than uploaded files, and 3) system metadata.

1. User uploaded files are immediately stored in Amazon S3, unencrypted but protected by access controls.
2. Application data is stored in a MySQL database on a virtual volume protected by industry-standard encryption. At present, a point-in-time consistent snapshot of that volume is taken every hour and stored in Amazon S3. These snapshots are saved with decreasing frequency, keeping all for the first 3 days, then daily snapshots for the next four days, then weekly for the next two months, monthly for the next four months, and semi-monthly for the remaining six months. No snapshots are saved for longer than one year.
3. System metadata, such as webserver logs, are stored on the same volume and with the same frequency.

This means that, in the worst case of data volume failure, at most one hour’s worth of application data (e.g. user activity, transaction data) could be lost. For enterprise applications, we utilize replication services for near-real-time assurance. If even greater durability than Amazon S3 storage is required, we can arrange to provide periodic remote backups to a physical datastore hosted by the client.

7.2.5 Internet Security

Like any company that utilizes Internet technology, Crowd Valley faces known risks from hackers and also from potential mistakes. We utilize a variety of methods to ameliorate such risks.

All IT systems, data volumes and other data resources are located behind access firewalls and protected by 2048-bit encryption. Not only access to systems, but also data volumes themselves, are securely encrypted.

Critical system services are automatically monitored to proactively warn technical staff of potential problems before any problems escalate.

System and data access within the company is carefully managed so that privileged access is only granted to trusted individuals on a minimum-needs basis, i.e. only to whom, as much as and for as long as needed.

Crowd Valley works with third-party security providers to securely manage and store certain sensitive data, such as credit card details, without directly touching that data, further reducing the possibility of unauthorized access to sensitive data by Crowd Valley, its clients or any outside entity.

Crowd Valley utilizes standard AWS security features, excepting MFA and HSM. AWS data centers are certified for compliance with the following data security standards:

• ISO 27001
• SOC1/SSAE 16/ISAE 3402 (Previously SAS70 Type II)
• PCI Level 1
• FISMA Moderate
• Sarbanes-Oxley (SOX)

7.3.1 Base SLA

Crowd Valley guarantees that the Platform will be available 99.9% of the time in a given month (no more than 60 minutes downtime per 30 day period), excluding Scheduled Maintenance, as defined below.

Platform uptime includes functioning of all Platform infrastructure but does not include the services or software that is provided by parties other than Crowd Valley via the Platform.

Platform downtime exists when Customer is unable to transmit and receive data and Crowd Valley records such failure in the Crowd Valley online support system. Network downtime is measured from the time that Crowd Valley becomes aware of that the Platform is not available or functioning in accordance with this Agreement until the availability of the Platform is restored.

"Scheduled Maintenance" shall include any maintenance in relation to which Crowd Valley provides Customer with no less than 3 Business Days notice and which may result in complete or partial downtime of the Platform.

7.3.2 Additional SLAs

Crowd Valley then provides additional tiers of Service Level Agreement according to response times and customer support requirements.

7.3.3 SLA reporting

Independent monthly reports are collected and made available to customers with an additional SLA.

Crowd Valley’s long-term position in this market is to be a provider of infrastructure and support services. We intend to enable this position by focusing on three long-term goals: (1) building out a global developer ecosystem; (2) supporting and evangelising the growth of online financial marketplaces; (3) scaling technology.

7.4.1 Global Certified Developer Ecosystem

Since the beginning of 2014, Crowd Valley has invested in running three-month training programmes for technology agencies and freelancers who have an interest in learning how to build online finance marketplaces of various types using the Crowd Valley API.

The course involves learning about the emerging market for these online finance platforms, working with various third-party APIs for relevant services such as ID verification or payments, as well as developing in Crowd Valley’s technology environment.

In order to complete the course each developer will have effectively created a new online funding platform using Crowd Valley’s APIs, whilst also demonstrating excellence in communication and problem solving skills.

By the end of 2014, over 30 developers had successfully completed the training course in countries as diverse as Argentina, Belarus, Hong Kong, Romania, United Kingdom, United States, Ukraine, Vietnam and Venezuela. These developers are now available to our customers on a freelance or contract basis, so that our customers do not need to continue coming back to Crowd Valley for every small update or bug fix if there are more appropriate local resources available.

7.4.2 Support, Education and Developer Toolkits

Crowd Valley consistently invests in creating research reports, guides, tutorials, regulatory news updates and newsletters to increase the level of education around digital finance marketplaces in the financial services sector.

In addition the company provides standard Developer Toolkits in several major programming languages to support partners, customers and developers to build robust platforms on top of the Crowd Valley infrastructure.

7.4.3 Scaling Technology Infrastructure

In line with our global customers’ growth Crowd Valley will invest in a more geographically distributed technology architecture to reduce latency and response times around the world.