Introduction
When discussing the development of fintech applications, teams often look to architecture as their sole basis of technical choice and do not consider other factors; however, in reality, these architectural decisions are all based on business decisions first. The architecture that is selected affects how quickly your application can launch, how easily you can evolve the app over time, how much your platform will cost to support and maintain in the long term, and how ready you will be for audit, compliance, and operational risk reviews. For founders and C-level teams, the final architecture chosen is of far more importance than whether or not the architecture sounds modern because of the impact it has on their business success.
Through our experience at Appricotsoft, we have seen teams either complicate their choices early on or remain too simplistic for far too long, which neither provides benefit to the end product. The objective in selecting an architecture is not to find the trendiest solution; the objective is to find an architecture that is aligned with your stage of product development, your team’s level of experience, level of regulatory pressure, and road map.
Architectural alignment with these drivers is extremely important in the area of FinTech, as too often your FinTech application exists in a greater strategic ecosystem than simply being an application. Typically, the FinTech app resides within a big-picture perspective between identity verification, payment applications, integration of bank suppliers, reconciliation, customer support processes, anti-fraud measures, reporting requirements, and security measures. Making poor architectural choices creates more than just technical debt; making poor architectural choices creates delivery risk.
This is why we treat architecture as part of product strategy. It has to support fast iteration, but it also has to protect trust. And in fintech, trust is everything.
Why the Architecture of Fintech Matters
There are many industries where you can patch up a problem later on… in FinTech, you’ll pay a heavy price if you do that.
If a payment gets delayed, there’s a double transaction, the balance isn’t consistent, there’s no ability to audit the transactions easily, or you don’t handle retrying transactions well; this all impacts how your users feel about you and how you’re perceived with compliance.
If your system doesn’t have a clear understanding of what happened, the timing of what happened and the reasons for what happened, you’ll be causing problems for your operations team, customer support team, and, subsequently, your users.
Therefore, a good FinTech software development company shouldn’t start with debating buzzwords like “monolith vs. microservices”. Instead, they should begin with such questions as:
- What are the most sensitive workflows in this product?
- What must be tracked for compliance and for support?
- Where are the potential failure points?
- Where do I need to have quick response times and where do I need to maintain control?
- What can the team reasonably and successfully operate 6 months after launch?
When posed with these types of questions/answers, a FinTech software development company would typically end up with a much better architecture than simply trying to replicate a large bank’s or a large scale payment company’s architecture.
Option 1: The monolith
A monolith is a single application that contains most of the functionality for a business, all within one code base and deployed together. While the idea of using a monolithic architecture may seem dated, it is still very much a viable option for many of today’s early-stage fintech products.
By having a well-structured monolithic architecture, your development team will be able to quickly launch their initial product,t as there will be fewer moving parts to contend with when working with their monolithic system. In order to quickly ship code, you can refactor code locally, test locally, deploy easily, and keep operational overhead to a minimum. If you are still working through the process of validating your onboarding experience, or your KYC flows, your payment journeys, or wallet logic, having that simplicity in your architecture will give you a leg up.
For an MVP, a monolith often makes sense when:
- The team is small,
- The roadmap is still changing,
- The product is finding product-market fit,
- The transaction volume is manageable,
- and the company needs to move carefully without creating unnecessary infrastructure complexity.
The biggest misconception about a monolithic architecture is that it automatically means you have a messy system. A monolithic architecture can be well-structured, modularized, tested, and production-ready if it is built using defined domains.
Many fintech startups will start out using a modular monolithic architecture. This simply means that you have one deployable application but have modularized the various domains, such as users, onboarding, KYC, payments, ledgering, notifications, and admin tool internally. This gives you the speed of a monolithic architecture but the opportunity to transition to a microservice-based architecture much more smoothly, if you ever want or need to.
The downside is that as the business grows, a monolith can become harder to scale organizationally. Large codebases increase coupling. Releases become riskier. Teams step on each other’s work. And if one domain suddenly has very different scaling or security needs, the single-application model can start slowing you down.
Still, for many founders, the better question is not “Is monolith old?” It is “Can a modular monolith get us to traction safely?” Very often, the answer is yes.
Option 2: Microservices
Microservices break the platform down, so you can have multiple smaller services each providing a single business capability. In the Fintech industry, this could include having separate services for authentication, customer profile creation, KYC, payment processing, ledger management, notifications, reporting, fraud, or systems integration.
Microservices have true potential once the company and product are ready to implement this model.
It is normal for businesses to consider microservices if:
- Different sections of their platform have different rates of change.
- Some functions require independent scaling.
- Teams that are integrated need to work independently of each other.
- Integration becomes increasingly difficult to manage.
- There are problems coordinating deployments across the platform.
For instance, assume you have a Transaction Engine, Reporting Layer, and Notification System that have different performance or release cycles; it may make sense to break those systems apart. The part of the ledger relates far more strictly to a release than a piece of marketing notification. Microservices give you the ability to design around these realities.
However, implementing microservices will also add complexity to your system instead of removing it.
In replacing internal method calls with network calls, you’ve added a level of complexity. Moving from managing a single deployment pipeline to many increases the complexity you have to manage. Moving from managing one set of logs to managing observability across distributed services will require a lot more work than just relying on the built-in functionality of your application. Moving from managing a single database transaction boundary to dealing with consistency across services will increase the amount of work required to build a functional application.
That last point is where many fintech teams underestimate the cost.
In a monolith, strong consistency is easier because related operations often happen inside a single transaction. In microservices, distributed transactions are much harder. That is why teams often rely on patterns like sagas or event-driven workflows to keep state aligned across services. Microsoft’s architecture guidance describes the saga pattern specifically as a way to maintain data consistency across services in distributed systems.
This does not mean microservices are a bad choice. It means they should be earned, not assumed.
A product with a 6-person team, one core transaction flow, and an evolving business model usually does not need ten services. A scaling fintech with multiple product lines, mature engineering practices, strong DevOps ownership, and strict domain separation often does.
Option 3: Event-driven architecture
Event-driven architecture is often mentioned in connection with microservices, but it actually serves a different purpose.
In event-driven architectures, parts of a system respond to business events, such as a user registering, KYC approval, payment initiation, payout settlement, card freezing, or suspected fraudulent activity.
Events allow parts of a system to react asynchronously rather than having all workflow processes depend solely on synchronous request/response calls. This is particularly beneficial in the financial sector,r where many business processes have multiple steps, heavy integrations, and are not instantaneously available.
For example, the payment flow is an excellent example of how long a series of events can take before being completed. A user action may trigger transaction authentication, fraud detection, ledger updating, notifications, reconciliation measures, and report generation. There is no need for all these processes to occur in one synchronous request. In fact, trying to force everything to happen in a single request can make the overall system less reliable.
Event-driven architecture decouples components and enhances resilience. However, it also requires a level of discipline in designing for the operational challenges associated with asynchronous processing, such as retry, duplicate ordering, observability, and eventual consistency.
Teams often struggle with operational challenges when using event-driven architecture. They love the flexibility of events, but don’t take into account the operational realities in designing their solutions.
What Do You Choose?
The Define Fintech Development process is about practical knowledge, not ideology. Answering the question of How to Choose a Framework will have a staged approach.
1. Modular Monolith (MVPs/Initial Traction): The level of complexity and the amount of development to deliver your product will determine whether to build a modular monolith or the more complex alternative of splitting out your features into separate applications.
Advantages: Your first product will be faster to develop, allow for quicker testing and auditing, and have little ongoing operating costs.
2. Service Extraction (Selective): After building on a modular monolith, extract the services that would allow continued development and separation of those services (e.g., Ledger, Payment Orchestration, etc). An important factor when considering whether to extract a service is to evaluate the complexity of the service.
3. Event-Driven Where It Adds Business Value: Using events to support workflows will provide you with the ability to use them as a decoupling mechanism, build resilience with your products, provide for replayability of the event, and create the ability to provide asynchronous processing for your event without requiring that you create an event-based development model for every feature of your application.
In conclusion, starting from a simple MVP through a testing/auditing environment will generally provide you with a more effective solution than starting from a service-based architecture, simply because it sounds like an enterprise architecture solution.
Designing APIs in Financial Technology: Why Simple is Better Than Clever
API Design is important as it can be viewed as a system of risk boundaries. APIs will define who can perform which task(s) under what conditions, how they will validate the task(s), and provide an audit trail of the actions performed.
Excellent API Design must focus on the following concepts:
- Explicit Contracts;
- Clear Versioning;
- Predictable Error Handling;
- Strong Authentication and Authorization;
- Idempotency with Retries; and
- Traceability across Requests and Downstream Processing.
Founders of companies typically only measure whether the API “works.” However, Experienced Teams measure whether the API operates safely when replayed under conditions of:
- Retrying;
- Partial Failures;
- Timeouts;
- Partner-Level Inconsistency (i.e., when your system relies on third-party suppliers as a source of KYC, Open Banking, Payment Processing, Fraud Checks, and Notifications).
The API Layer must isolate external (third-party) complexities from being emitted into the rest of the platform.
When we assemble Mobile Application Development Services for Fintech Products, we tend to recommend that the business contain an internal domain logic that is separate from the Components of the Public / Partner API. Keeping domain logic and Public APIs separate supports versioning, security control, and a long-term strategy for maintainability.
Data Consistency: The Transition to Physical Architecture
This is the point where your theoretical architecture becomes actual architecture.
In the Fintech industry, data consistency is much more than just a database item. It permeates money movement, status visibility, support resolution, reconciliation, reporting, and customer trust.
In monolithic architectures, strong consistency is much more straightforward to achieve because you can conduct multiple actions within the same transaction boundary.
When using microservices and event-driven systems, you normally need to balance strong consistency with availability, resiliency,e and decoupling – which often contributes to an eventual consistency approach in part of your system.
This is acceptable provided it is a conscious decision.
End users are willing to live with the “processing” state for a defined period. They will tolerate a brief period of time before they receive notification. They will not tolerate balance discrepancies that cannot be explained, duplicate charges, es or irreversible confusion.
For that reason, fintech architecture must clearly define:
- Which workflows need strong consistency.
- Which workflows can have eventual consistency.
- Which is the authoritative source of truth for each domain.
- How state transitions will be tracked.
- How support teams will be able to understand what occurred.
And lastly, the design of your ledger deserves special consideration; in many fintech solutions, the ledger (transaction history) will become the operating foundation of the solution, a nd as such, should not be treated as an afterthought.
Idempotency: one of the most important fintech design rules
The essence of idempotency within the fintech space is to create an overall system where, no matter how many times you retry a single request through the API, you will receive the same result (no additional records) if you have the same idempotent key or identifier.
In order for an overall system to be truly idempotent, you must have a high degree of confidence in your ability to keep track of previously made requests.
This can be seen when considering that retries are common between all systems, from mobile phone networks, where an error can cause a timeout, and clients may resubmit their requests, to queues that reprocess messages due to the failure of a previous consumer, to humans clicking multiple times.
When Stripe’s API documentation refers to this principle, it is explained that when a first-time request is made with an idempotency key, the results of any future attempts using the same idempotency key will yield the same result.
From a practical perspective, and depending on the type of technology used by your fintech team, you should consider the concept of idempotency when creating:
- payments,
- payouts,
- transfers,
- webhook handling,
- external provider callbacks, and
- event consumers.
A mature architecture cannot merely assume, “this will probably not happen.” A mature architecture must assume that duplicates will exist, and that retries will happen, and design accordingly.
Designing for regulatory requirements from day one
In order to meet regulatory requirements from the very first day of a project, a thoughtful approach to architecture and design should be taken. Regulatory requirements for your product, such as KYC, PSD2, AML, payment data, audits, and incident response, can shape your product’s architecture and framework from the outset. These regulatory requirements have particular importance and relevance to FinTech-related work (PSD2, open banking, KYC, payment integration, fraud, etc.).
That does not mean overengineering. It means building the right controls early:
- clear audit trails,
- role-based access,
- environment separation,
- secure secrets handling,
- immutable or well-tracked critical records,
- documented data flows,
- and operational visibility into sensitive workflows.
You must take into consideration the realities of where your regulated and sensitive processes live. Not every service should have access to every type of information or data (a good architecture will create a limited blast radius).
At Appricotsoft, we believe that architecture must provide for predictable delivery, visibility of risk, and quality to be built in during the workflow process instead of being added to the workflow at the end of the project. This approach aligns directly with our Unison Framework; sharing project artifacts, providing weekly demos, establishing clear trade-offs, using AI to support execution, while individuals remain responsible for results.
When delivering in the FinTech space,e it is critical to have delivery discipline because your architecture decisions are not just technical decisions; they have fundamental impacts on compliance, confidence in releases, and business control.
What we usually recommend to fintech founders
The general rule of thumb for Fintech founders who have created a New Fintech Product or simply want to re-imagine an existing Fintech Product is to go with the “simplest” architecture that will meet your regulations and at the same time support your Product.
For most Fintech companies, this will mean using:
- A modular monolith
- Clearly defined domain boundaries
- Strong API Contracts
- Adequate Audit Logging
- Idempotent Critical Operations
- Selective use of Event Driven Processing to assist.
Only move to Microservices when you believe you can do it for good reasons, not just wishful thinking. And as you design your Systems, focus on clarity. The next team that works on your Fintech Product needs to be able to explain what happened or how things were built when there is an incident; handle what happened as a result of decisions made; gain approval for your Products; provide better or different support to users; and be able to continue evolving the Product without concern for your Architecture limiting them.
At Appricotsoft, we like creating Software that we are proud of – Practical Software, Well-thought-out, and Honest about the Trade-Offs Sacrificed. This is part of our broader view that Development should be a combination of Quality, Responsibility, Transparency and not just Technical Aspirations.
If you are considering launching a New Fintech Product or re-designing an Existing Fintech Product, the Best Architecture is NOT necessarily the Most Complex Architecture; it is the Architecture that will allow you to Go Live with confidence, operate with clarity, and Scale without Losing Control.
Suggested internal links to add in the published article
- Link a sentence about phased growth to Appricotsoft’s fintech roadmap article.
- Link a sentence about security and trust to Appricotsoft’s secure-by-design fintech article.