How Dutch Fintech Startup Floryn Obtained a PSD2 License Using AWS

Guest post by Milo Oostergo, Principal Solutions Architect, AWS Startups, and Marijn van Aerle, CTO, Floryn

Floryn is a fast growing Dutch fintech startup helping small and medium sized enterprises (SMEs) grow by providing business loans. In two minutes, businesses can create an account, upload their bank statements, and get a credit decision within 24 hours. This all powered by artificial intelligence (AI) and machine learning (ML) technologies leveraging historic payment transactions to and from a business.

In 2019, Floryn started the process to obtain a PSD2 license to also provide customers with insights into their liquidity management and financial health and simplify the customer experience of requesting a business loan. The PSD2 license enables Floryn to integrate directly with popular banks and eliminates the need for customers to manually upload PDF files with payment transaction data. This helps reduce errors and also helps make higher quality decision by using up to 24 months of banking data instead of 6 months. To obtain the PSD2 license, Floryn produced extensive documentation and supporting evidence that was submitted to the local regulator covering topics such as business case, control, integrity, governance, and financial stability.

To support the objectives of PSD2, Floryn also started a redesign of their AWS infrastructure following European Banking Authority (EBA) guidelines and leveraging the best practices of the AWS Well-Architected Framework.

Building a PSD2 Compliant Infrastructure on AWS

Floryn was born in the cloud in 2016, with infrastructure running on AWS using mostly Amazon EC2. As part of implementing the requirements to obtain a PSD2 license, Floryn used the opportunity to also modernize their architecture, improve scalability, and reduce costs.

Pictured: Example of the guidelines from the EBA on Access control

Moving to a Multi-account Setup and Implementing Proper Access Controls

To implement proper access controls and gain the ability to centrally manage and govern multiple accounts, Floryn moved a multi-account AWS environment. In AWS Organizations, Organizational Units (OU) were defined to create a top level segregation of the different environments (development, staging, and production), and within each OU, separate AWS accounts were created for the different components. For example, the service that interacts with the banking APIs runs in an isolated AWS account. In addition, a set of foundational OUs were created and used for shared infrastructure services such as IT services, billing, access management, and logging. Access to the accounts is granted following the least privileged principle. On a quarterly basis, access rights are reviewed by Floryn’s Access Management team and an internal auditor to support the PSD2 auditing objective.

Pictured: Floryn’s multi account setup

Move to Infrastructure as Code

To reduce human error and increase automation, Floryn adopted Terraform and started implementing their infrastructure as code. Terraform provisions resources in a safe, repeatable manner, allowing Floryn to build their infrastructure and applications without having to perform manual actions or write custom scripts. Terraform takes care of determining the correct operations to perform when making changes to the infrastructure and rolls back changes automatically if errors are detected. All infrastructure changes are reviewed by peers and are automatically tested through a CI service that enforces tests to pass. Code reviews are enforced on all tickets before the changes are deployed by the continuous deployment service.

Leveraging Serverless and Managed Services

Floryn started taking full advantage of serverless and AWS managed services to improve their security posture. They implemented an immutable infrastructure by moving all their applications and services to containers running on AWS Fargate with Amazon ECS. Fargate avoids the operational overhead of scaling, patching, securing, and managing servers and ensures that the infrastructure the containers run on is always up-to-date with the required patches.

The containers store temporary data in attached volumes, and volumes are re-created on every deployment. Amazon S3 is used for persistent storage of non-relational data such as files and large datasets. Relational data is stored in a multi-Availability Zone (AZ) RDS PostgreSQL database managed by Amazon RDS. All data is encrypted at rest leveraging AWS Key Management Service.

Adoption of AWS Security services

Pictured: Example of the guidelines from the EBA on monitoring

The EBA guidelines require companies to establish, implement, and monitor various security measures. By leveraging AWS Security services, Floryn met this requirement in a scalable and cost-effective way while improving their security posture.

Floryn adopted AWS Config to assess, audit, and continuously monitors the configurations of their AWS resources. Amazon GuardDuty was adopted for threat detection and continuous monitoring to generate detailed and actionable security alerts. Engineers rotate being on-call to respond to alerts that come in on a dedicated Slack channel, and there is a monthly security meeting during which all issues are reviewed to see if processes need to be adapted.

AWS CloudTrail is used to continuously monitor and log account activity related to actions across the AWS infrastructure. For centralized application logging and metrics collection, Floryn adopted AWS Cloudwatch. Cloudwatch Alarms are tied to Slack notifications to inform the teams about possible service issues (ie. memory usage, container health, cpu usage, etc.).

The container applications that require access to other AWS services got Amazon IAM roles associated with an ECS task definition. Credentials and secrets for database and third-party services are all securely stored in AWS Systems Manager Parameter Store and restricted to the IAM role associated with the specific ECS task. An AWS Transit Gateway ensures secure communication between the VPCs of the applications in different AWS accounts. Using VPC Flow Logs traffic between the AWS accounts is being monitored.

To help protect their application against common web exploits and bots that may affect availability, compromise security, or consume excessive resources, Floryn enabled AWS WAF on the Application Load Balancers.

Roadmap

Floryn is constantly looking for opportunities to reduce operational overhead and improving their security posture. The team is currently implementing the recently launched Amazon ECS Exec feature to eliminate the current SSH bastion container to debug high-severity issues encountered in production. The Data Science team is moving their ML ops process to Amazon SageMaker. To avoid downloading sensitive data, the Data Science team build and train models in a network-isolated Amazon SageMaker environment. This avoids the need to download sensitive data to local development environments.

Summary

Taking full advantage of the broad AWS service offering helped Floryn simplify their architecture and meet with EBA guidelines.

• Adopting AWS managed services and serverless means that they no longer have to worry about keeping up to date with the latest security patches.
• Leveraging the AWS security and compliancy services helps them audit and monitor their entire environment and stay on top of compliance violations and security incidents.
• AWS Well-Architected and a performing Well-Architected Framework Review helps design an architecture leveraging AWS best practises and identify opportunities to further improve and secure the architecture.

With the supporting documentation and EBA Financial Services Addendum signed with AWS, Floryn was able to meet and exceed the local regulators’ expectations and obtain their PSD2 license in 2020.