Source: [Architecture for operated financial services](https://fireflysoftware.io/openplatform/architecture/) Description: How Firefly connects channels, workflow, AI agents, systems of record, and evidence in a financial operation. Language: en [Home](https://fireflysoftware.io/)/OpenPlatform / Architecture # Every action has an owner and leaves a record. The architecture follows a service through five layers, from the request to the accepted output. [Discuss your service architecture](https://fireflysoftware.io/contact/) [Explore our services](https://fireflysoftware.io/services/) From the request to the record ## The layers behind a service. 1. 01 ### Channels and intake Receive requests through the agreed customer, partner, and system channels. 2. 02 ### Service coordination Track case progress, owners, and the permitted next actions. 3. 03 ### Execution and AI agents Use AI agents, AI models, and approved rules to do the work. 4. 04 ### Systems of record Update or reconcile your systems through authorized interfaces. 5. 05 ### Oversight and evidence Keep the records that measure delivery, show decisions, and support recovery. In the open modules ## Seven layers, from channels to provider systems. Firefly’s architecture in seven layers, from top to bottom. Channels, where every journey starts. Process and decisions: AI acts within approved limits where regulation allows, and a person with delegated authority decides significant or out-of-limit cases. Firefly modules, which run the business. Data and analytics. Integration: adapters plugged into the API and events backbone. Your core systems, kept and connected. And provider systems, always behind an adapter. Open a layer to see what it contributes and where its work ends. 01 **Experiences** Journey APIs for customers and operators. Web and mobile experiences, partner portals, and operations tools call journey APIs, each with its own entry point. - exp-onboarding - exp-accounts - exp-distributor 02 **Business domains** Commands, queries and coordination across capabilities. Domain services coordinate the core services; an account-opening saga links the agreement, holder, account, and first transaction. - domain-banking-accounts - domain-customer-people - domain-product-catalog 03 **Core records and services** Focused APIs, data models and persistence. Each core module owns one record, such as a party, a contract, or an account, behind REST/OpenAPI contracts. - core-common-customer-mgmt - core-common-contract-mgmt - core-banking-accounts 04 **Integration boundaries** Provider systems, connected in one place. Provider interfaces keep payment rails, documents, signing, and insurer systems behind explicit contracts, with error handling and reconciliation. - library-rails - library-psps - fireflyframework-ecm Design principles ## How the work stays under control. ### Match the technology to each step AI agents work multi-step cases; AI models read and draft. Where an error is costly, calculations, permissions, and postings run on deterministic code. ### Design the exception path alongside the normal path Delays, ambiguous evidence, and partial failures are part of the process, so the service defines how to pause, resume, and reconcile. ### Keep institutional authority visible A proposed action is not an authorized one, and delegated limits apply to automated and human work alike. Inside a service ## Keep business logic independent of its connections. A port says what the use case needs and an adapter supplies it, so a new database or provider stays inside its adapter. A service with explicit ports. In the middle, the use case: an amber brick holding the domain model, with the business rules on top. It takes requests through the API pipe and publishes events on the amber events pipe for other services. Behind, on their own ground, the database that keeps its business records and an external provider, each reached through a steel adapter plate plugged into the APIs. Changing the database or the provider means changing its adapter, not the use case. Reference view · a service built with explicit ports 1. 2 **Repository port** Persist business records Selected relational database 2. 3 **Event publisher** Notify other services Selected message broker 3. 4 **External-service port** Request a provider action Provider API adapter Architecture decisions ## Design for the whole operation. ### API contracts Define inputs, outputs, authorization, and versions, with idempotent retries where the service supports them. ### Data and events Choose which service owns each record, and use event sourcing where it earns its place. ### Process state Keep long-running work in a persisted runtime; in-memory timers die with a restart. ### Identity and access Separate who a user or service is from what it may do, with OAuth2/JWT and policy contracts. ### Operational evidence Trace every request, and agree how to reconcile when an external system acted but its response was lost. ### AI within limits Model output is typed information; permissions and your approval decide what proceeds. Open engineering foundations ## The frameworks behind the design. Firefly Framework supplies the service, data, event, security, process, and AI patterns the platform uses. [Explore the frameworks](https://fireflysoftware.io/technology/frameworks/) [fireflyframework.org](https://fireflyframework.org/) Your first operation ## Bring us one operation. Tell us the process, the volume, and what “done” looks like. We will come back with a scope, a deployment plan, and a proposal. [Discuss your service architecture](https://fireflysoftware.io/contact/) [Request a demo](https://fireflysoftware.io/contact/?request=demo)