Data, application, and API security
This page covers how borrower and loan data is protected at rest and in transit, how the application defends against common web-application risks, how APIs are authenticated and authorized, and where identity, business, and fraud checks fit into the lending flow.
Data encryption
Data is encrypted both in transit and at rest.
| State | Protection |
|---|---|
| In transit | HTTPS using TLS 1.2 or later for all external connections, including API traffic and portal sessions |
| At rest | Databases, file storage, and backups encrypted at rest using the mechanisms provided by the underlying cloud platform, typically AES-256 |
| Keys | In cloud deployment, encryption uses provider-managed keys by default. Customer-managed keys can be used where supported by the selected cloud services and deployment configuration. |
Data segregation and minimization
Each deployment isolates its data. Personally identifiable information is confined to the records that need it, retention periods are configurable to the institution’s policy, and the data model supports the data-subject operations that privacy regimes require (access, correction, and erasure) handled operationally through administration. Tenancy (single- or multi-tenant) is set at deployment.
Application security
Secure development addresses the OWASP Top 10 categories of web-application risk — including injection, broken access control, and security misconfiguration — through the development lifecycle rather than as an afterthought. Controls include input validation and output encoding, enforced access checks on every request, dependency and vulnerability scanning, and peer code review before release. The secure development lifecycle behind these controls is described on the Compliance and secure development page.
API security
HES LoanBox is API-first, and the API is governed by the same identity layer as the interface. Every platform API request requires a valid Keycloak-issued token, is authorized against the caller’s roles, and runs over HTTPS, with tokens scoped to the minimum required permissions. Third-party services are connected using a unique authentication credential for each integration point, so each connection’s access can be controlled and revoked independently. The open API is also how integrations are built onto the platform.
KYC, KYB, and sanctions screening
HES LoanBox integrates with third-party providers to incorporate individual identity verification (KYC), business verification (KYB), sanctions and politically exposed person (PEP) screening, and document checks into the application workflow. Step-up identity checks can be required when a case needs stronger assurance. A predefined set of provider integrations is available out of the box, while customer-specific provider integrations are implemented through customization as part of project delivery.
Note
Anti-fraud
HES LoanBox includes pre-configured fraud-prevention checks that can be fine-tuned to the institution’s risk profile and business model. Ondato and Jumio are tools used by default, and additional third-party fraud tools can be connected. Credit decisioning through GiniMachine can incorporate fraud and risk signals alongside creditworthiness, including at origination.