Technical & Platform Overview
Last updated
Was this helpful?
Last updated
Was this helpful?
This document provides an introduction to FundApps' shareholding disclosure service and its platform. FundApps provide shareholding disclosure monitoring services via a hosted web application 'Rapptr'. Rapptr is provided via FundApps controlled infrastructure from secure and strictly controlled hosting environments. We maintain the software, continuously updating with the latest software enhancements and legislative content updates.
Rapptr works on a batch processing model; position data is uploaded to the system and processed in the background. Typically customers implement an automated upload job from their systems to the API endpoints provided by FundApps to receive this data. Documentation of our API and example implementations are publicly available.
Users of the system may choose to receive notification e-mails letting them know when this process has concluded and results are available inside the system. Users use a browser-based user interface to view the results of running the batch job and follow a workflow inside the software to investigate any results and file disclosures. Historical data from checks is retained within the system to provide a timeline of results and to facilitate correct calculation of disclosure requirements.
Rapptr is kept constantly up to date with the latest enhancements and fixes. We continuously deliver changes from development and content teams to customer production environments. To support this activity we employ a best practices-based development approach employing test-driven development, pair programming and code review to reduce risk and improve software quality.
Every change to our software and rule content is run through an ever growing test suite to ensure a minimal amount of risk in this continuous update process. Security considerations are built into our software lifecycle; we identify work items early on that have security implications. A number of our customers have penetration tested the application and do so on a recurring basis.
Deployment of changes of the Rapptr software is a fully automated and hands-off process.
As we have control over both software and infrastructure we are able to deliver best in class availability and security. The principle of least privilege is applied throughout; at the network, system and software levels to tightly control availability of data and reduce the potential for security breaches.
All customer data sent to or generated inside Rapptr follows an Encrypted Data Lifecycle; all interactions with system occur over an encrypted protocol: Secure HTTP (HTTPS). We keep our supported cipher suites for the SSL encryption used for HTTPS in line with industry standards and regularly run external tests to verify this. The results of these tests are publicly available. Once data enters Rapptr it remains encrypted in transit throughout our networks, which have additional security and privilege measures in place.
On our AWS infrastructure, this data is subsequently encrypted at rest and employs a key management system which allows us to rotate the keys used for the encryption of these volumes on a regular basis. Backups are also stored encrypted at rest, meaning data is never available in the clear to be read by third parties.
Access to Rapptr is via HTTPS; either for user interactions to the Web UI or for automated interactions with the API endpoints. We are able to provide further access security by applying IP restrictions to customer environments, preventing access from networks other than those of the customer site. These restrictions operate at a high level, before any authentication to the system and prevent any requests being made to the application at all.
Individual customer datasets are isolated at infrastructure level using separate databases. A complete audit trail is visible inside the application and allows tracking of all operations taken inside the system, along with user access events. This auditing includes any support activities performed by FundApps staff.
Our platform is hosted in facilities with top grade physical security; we host entirely within the EU with Amazon Web Services (AWS). AWS hold industry standard certifications relating to security and availability, including but not limited to ISO 9001, 27001 and SOC I, II certifications. Full details of the certification activities undertaken by our hosting partner are available via AWS compliance.
We ship all log events generated on the platform to a central store for audit, reporting and alerting activity. Direct access to production systems is strictly restricted, to key personnel with a direct operational need and these accesses are reviewed on a monthly basis.
We have automated monitoring of critical conditions for both infrastructure and software in the platform. These conditions create alerts following escalation policies and where necessary alert operators on a 24/7 basis to preserve the integrity and availability of the platform.
Application performance and infrastructure metrics are used for capacity planning and platform management; ensuring there is always sufficient capacity available across the platform to satisfy all demands.
Our AWS stack is designed with two primary failure modes: Failover and Disaster Recovery. Failover is catered for entirely within a single geographic region using a highly available primary environment. In this primary environment data is replicated synchronously between two database servers and redundant systems are used to ensure the maximum possible continuity of service.
These redundant systems are distributed between two AWS Availability Zones (AZs) in a single geographic region (Dublin, Ireland). AWS have multiple AZs per geographic region, but each AZ has discrete power and internet connectivity. We use two availability zones simultaneously for web traffic, reducing the effect of any failure on the availability of the service.
Disaster Recovery functionality is provided from a secondary geographic region (Frankfurt, Germany) and this mode is intended to meet a 4 hour RTO in case of total loss/failure of the primary environment. This is facilitated by shipping backups on a regular basis to encrypted storage in the region.
Configuration management and automation allows spin up of the other platform components in this region to support a deployment of the system in the absence of our primary geographic location.
