7.1.1 Introduction #
The NovaFacies Open Source FinTech Framework (NFF) follows an API-first, modular, and flexible design philosophy. It is not a predefined technology stack but a set of guidelines that allow organizations to build financial applications in a structured and interoperable way.
Implementations can vary—from custom-built microservices to Backend-as-a-Service (BaaS) platforms to low-code solutions—as long as they adhere to the API standards and interoperability principles defined in NFF.
This section outlines the general architecture of an NFF-based solution while maintaining flexibility for different deployment models.
7.1.2 Core Architectural Components #
While the exact technology stack is not dictated, a NovaFacies-compliant system typically consists of the following core components:
1. API Layer (Required)
- The only mandatory component of an NFF-based solution.
- All business logic and data interactions must be exposed via APIs.
- APIs must follow industry best practices (e.g., RESTful or GraphQL, OpenAPI standards).
- Authentication and Authorization must use secure mechanisms such as OAuth2, JWT, or API keys.
- Can be implemented as:
2. Functional Modules (Optional, Recommended)
- Functional modules represent business capabilities, such as:
- KYC/KYB – Identity verification and onboarding.
- Transaction Processing – Payments, remittances, settlements.
- Compliance & Fraud Detection – Risk monitoring, AML checks.
- Reporting & Analytics – Data insights and financial statements.
- Modules can be implemented as:
- Microservices (separate deployable services).
- Monolithic components (single backend application).
- Serverless functions (event-driven functions).
- External APIs (third-party integrations, such as Onfido for KYC).
3. Data Layer (Optional, Recommended)
- Stores and manages financial data, user information, and transactions.
- Can be implemented using:
- SQL Databases (PostgreSQL, MySQL) for structured financial records.
- NoSQL Databases (MongoDB, DynamoDB) for unstructured or semi-structured data.
- BaaS storage for serverless implementations.
4. Integration Layer (Optional, Recommended)
- Ensures smooth communication between internal services, third-party providers, and external banking APIs.
- May include:
- Middleware to connect different financial services.
- API Gateways (e.g., Kong, Tyk, Apigee) for traffic control.
- Event-driven architecture using message queues (Kafka, RabbitMQ).
5. Frontend Layer (Optional, Recommended)
- Consumes the API Layer to provide user interaction.
- Can be built using:
- Web Applications (React, Angular, Vue.js).
- Mobile Apps (iOS/Android, Flutter, React Native).
- No-code/Low-code solutions (Appsmith, Budibase).
- Embedded Finance components (integrated into third-party platforms).
7.1.3 Deployment & Infrastructure Considerations #
An NFF-based solution can be deployed in multiple environments, depending on business needs:
| Deployment Model | Description |
| Self-Hosted | Traditional infrastructure (on-premise or private cloud). |
| Cloud-Based | Hosted on public cloud platforms (AWS, Azure, GCP). |
| Hybrid | A mix of cloud and on-premise services. |
| Serverless | Fully event-driven architecture with minimal infrastructure management. |
Regardless of deployment, security, scalability, and observability should be prioritized.
7.1.4 Security & Compliance Considerations #
While NovaFacies does not enforce specific compliance certifications, all implementations must follow industry security best practices, including:
- Authentication & Authorization: Secure access control mechanisms (OAuth2, JWT, API keys).
- Data Encryption: All sensitive data must be encrypted in transit (TLS 1.2+) and at rest (AES-256).
- Compliance Readiness: Support for financial regulations such as:
- GDPR (Data Protection).
- PSD2/Open banking (Secure APIs).
- PCI-DSS (Payment Security).
Security should be a built-in design principle, not an afterthought.
7.1.5 Extensibility & Future-Proofing #
Since NovaFacies is designed to be modular and adaptable, implementations should prioritize:
- Backward Compatibility: APIs should remain stable across updates.
- Standardized formats: JSON, OpenAPI, and ISO 20022 for financial messaging.
- Community contributions: Open-source components should follow best practices for extensibility.
7.1.6 Summary #
The NovaFacies architecture is not a single rigid structure but a framework of principles that ensure any implementation remains API-first, modular, and interoperable.
| Component | Required? | Description |
| API Layer | Yes | The core requirement, ensuring interoperability. |
| Functional Modules | Optional | KYC, Payments, Compliance, etc. |
| Data Layer | Optional | SQL, NoSQL, or BaaS storage. |
| Integration Layer | Optional | Middleware, API Gateway, event-driven messaging. |
| Frontend Layer | Optional | Web, mobile, Embedded Finance UIs. |
By following this flexible but structured approach, developers can build solutions that meet business needs while maintaining compliance, security, and scalability.
