Advapay core banking features guide
The right checklist is not the longest one. It is the set of capabilities that fits the institution’s products, customer types, permissions, providers and operating responsibilities. A feature is only useful when it works end to end: the customer or operator can initiate the action, the platform validates it, the correct provider is called where necessary, the financial state is recorded, exceptions can be investigated and the result can be reconciled.
This guide explains which core banking features matter, how modules should work together and what evidence a fintech should request during vendor evaluation. It focuses on the controlled operating platform. For the broader category and selection framework, use Advapay’s core banking software guide. For the distinction between the core and the customer-facing experience, see digital core banking and digital banking solutions.
Core banking features at a glance
- Customers and products. Customer records, related persons, product rules, accounts, IBAN structures, currencies and statuses.
- Ledger and reconciliation. Double-entry postings, chart of accounts, statements, period controls, internal positions and external reconciliation.
- Payments and FX. Payment workflows, transfers, beneficiaries, currencies, fees, statuses and provider orchestration.
- Controls and operations. Roles, permissions, approvals, limits, audit history, queues, manual actions and exception management.
- Cards and channels. Card lifecycle management plus web, mobile, operator and partner interfaces where included in scope.
- APIs and providers. Defined interfaces to banks, rails, KYC/KYB services, card processors, FX/liquidity and other specialist systems.
Scope note: core banking software is not a licence, sponsor bank, payment scheme membership, KYC provider, card processor or guarantee of regulatory compliance. It provides the controlled software capabilities through which the institution implements its approved operating model. Legal permissions, policies, infrastructure, provider contracts and human decisions remain part of the complete service.
1. What counts as a core banking feature?
A core banking feature is a capability that creates, controls or explains part of the institution’s operating and financial state. It is not simply a screen or menu item. If the platform offers account creation, for example, the feature should define which customer and product can receive the account, generate or accept the required identifiers, apply currency and status rules, record who performed the action and expose the result to relevant channels and downstream systems.
That end-to-end definition prevents feature lists from becoming misleading. Two platforms may both place a tick beside “payments”, yet one may only capture an instruction while the other supports validation, approval, fee calculation, provider routing, intermediate statuses, postings, operator investigation and reconciliation. The label is the same; the operational coverage is not.
For procurement, it helps to divide requirements into four questions:
- What business object does the platform control? Examples include customers, products, accounts, balances, transactions, ledger entries, fees, documents or cards.
- What rule or workflow does it apply? Examples include permissions, limits, signatures, pricing, approval steps, status transitions and scheduled processing.
- What external dependency remains? The action may require a bank, payment rail, card issuer/processor, identity provider, liquidity provider or another specialist service.
- What evidence exists after the action? Operators and auditors may need event history, user identity, timestamps, provider references, postings, reconciliation status and any manual intervention.
This framing is more useful than asking whether the software has “all essential features”. Essential for whom? A remittance business, an EMI serving companies, a retail wallet and a crypto-fiat proposition can share the same account and ledger foundation while requiring different channels, providers, controls and operating procedures.
Feature breadth is not the same as product fit
A large catalogue can still be a poor fit when the platform cannot express the institution’s actual products or responsibilities. Conversely, a more focused platform can be appropriate when its controlled objects, configuration model and integration boundaries match the proposition.
Product fit should be demonstrated with the institution’s own example. Ask the vendor to configure a relevant customer type, account structure, currencies, tariff, limit and approval scheme. Then follow a realistic transaction from instruction through provider execution, posting, exception handling and reconciliation. This exposes assumptions that a generic presentation will not.
Configuration and custom development are different
Configuration changes behaviour through supported parameters, rules and workflows. Custom development changes or extends the software. Both may be legitimate, but procurement teams should know which is which.
Supported configuration is normally easier to test, document and carry across releases. Custom code can deliver differentiation, but it adds design, testing, upgrade and ownership responsibilities. During evaluation, label every important requirement as available, configurable, integrated, custom-developed or out of scope. Do not let the word “supported” hide these distinctions.
2. The boundary between the core, channels and providers
The most important architectural feature is a clear responsibility boundary. A controlled core should preserve the institution’s customer, product and financial state. Customer and operator channels should present services and capture instructions. Specialist providers should perform the external functions for which they are contracted.
| Layer | Primary responsibility | Typical capabilities | What it still depends on |
|---|---|---|---|
| Core banking platform | Controlled product and financial record | Customers, products, accounts, ledger, fees, payments, permissions, statuses, reporting and audit history | Business rules, approved operating procedures, provider access and deployment controls |
| Digital banking channels | Customer and staff experience | Web/mobile journeys, forms, notifications, instructions, self-service and operator interfaces | Core and provider APIs, authentication, product configuration and accessible data |
| Specialist providers | External service execution | Banking/rails, card processing, KYC/KYB checks, screening, FX/liquidity, crypto custody or data services | Contracts, technical integration, accepted risk scope and reconciliation with the core |
Consider a customer payment. The channel captures the instruction. The core validates account state, permissions, limits, fees and workflow. An external bank or rail may execute the movement. The core records the evolving transaction and posting state. The channel then shows the result, while operators retain enough evidence to investigate differences.
The same boundary applies to onboarding. A channel collects data and documents. A KYC/KYB provider may return verification results. The institution’s procedures determine whether automated or human decisions are permitted. The core and back office preserve customer status, related records and the history of actions. It is inaccurate to describe this whole chain as “built-in KYC” unless the precise provider, decision ownership and workflow are defined.
Why the boundary matters during change
Channels, providers and the core change at different rates. A mobile journey may be redesigned frequently. A bank or screening provider may be replaced. The controlled account and ledger history needs to remain stable through those changes.
When responsibilities are blurred, teams recreate financial rules inside apps, treat provider responses as the only transaction record or build manual spreadsheets to reconcile gaps. A modular design does not remove dependencies; it makes their ownership explicit.
3. Customer, product and account management
Customer, product and account management establishes the objects on which every later transaction depends. The module should support the customer types and legal relationships in the proposition, connect them to configured products and maintain the account structures required for operations and reporting.
Customer records and relationships
A serious customer model must go beyond name and contact details. Depending on the proposition, it can include private and corporate customers, addresses, identifiers, documents, company officials, beneficial owners, authorised persons, contact channels, risk or service status and links between related parties.
The platform does not decide which data is legally sufficient for every market. It should allow the institution to capture and control the data its approved process requires, and to integrate external verification services without losing the internal customer record.
For business customers, relationships are especially important. One company can have several users with different rights; one person can act for more than one company; payment approvals may depend on role or amount. Ask the vendor to demonstrate this explicitly rather than inferring corporate capability from a retail customer screen.
Product configuration
A product describes the controlled rules under which an account or service operates. Configuration may include customer eligibility, currencies, account types, tariffs, transaction permissions, balance or amount limits, required approvals, visibility in channels and linked provider services.
The platform should distinguish product rules from individual exceptions. If every customer variation requires a developer or database edit, the product model is not genuinely configurable. At the same time, configuration must be governed: who may change a tariff, limit or product status, when the change becomes effective and how the old value is retained for audit or historical calculation.
Accounts, IBAN structures and balances
Account management normally includes creation, maintenance, currency, identifiers, status changes, restrictions, balances and statements. Some models require one account per currency; others use multicurrency structures or several identifiers linked to a controlled account relationship. The appropriate design depends on banking partners, product rules, reconciliation and reporting requirements.
Ask how the platform represents available, booked, pending or reserved amounts. A single number labelled “balance” is often insufficient once authorisations, pending payments, fees or provider delays appear. The important test is whether the balance presentation can be traced back to controlled transactions and ledger positions.
Documents and lifecycle state
Customer and account records change over time. Documents expire, authorised persons change, accounts become restricted, products migrate and relationships close. The platform should preserve lifecycle state rather than overwrite the past without evidence.
Useful evaluation questions include: Can an operator see who changed the record? Are previous values retained? Can workflows require approval? Are effective dates supported where needed? Can closed or restricted records remain available for reporting without being used for new activity?
4. Ledger, accounting and reconciliation
The ledger is the foundation of the controlled financial record. It should record balanced postings, support the chart of accounts and give finance and operations teams a traceable connection between customer activity, internal positions, provider movements and reporting outputs.
Double-entry posting
A credible core banking platform should use explicit double-entry logic for financial events. Every posting should identify the accounts affected, debit and credit amounts, currency, value or booking date where relevant, business reference and the transaction or event that caused it.
The purpose is not accounting terminology for its own sake. Double entry makes it possible to prove that the internal record remains balanced and to trace how a payment, fee, FX conversion, card movement or adjustment affected customer and institutional positions.
Ask the vendor to show posting examples for your actual use cases. A polished balance screen is not evidence. Request the transaction, its ledger entries, reversal or correction behaviour, related provider reference and the resulting statement or report.
Chart of accounts and product accounting
The chart of accounts should support the institution’s accounting design and connect product events to appropriate internal accounts. Configuration may need customer liability accounts, settlement or correspondent positions, fee income, suspense or exception accounts, FX positions and other categories defined by the operating model.
The software should not claim that one default chart makes every client compliant with a particular accounting standard. The institution and its advisers remain responsible for accounting policy. The platform’s job is to implement the agreed chart, posting rules, periods and reports consistently.
Reconciliation
Reconciliation compares the core’s controlled record with external evidence. Depending on the service, that evidence may come from a bank statement, payment rail, card processor, liquidity provider, custody provider or another system.
A useful reconciliation capability can import or receive external records, match them using defined references and tolerances, identify unmatched or inconsistent items, route exceptions and preserve the resolution history. “We can export a spreadsheet” may be a starting point, but it is not the same as an operational reconciliation process.
Period controls, statements and adjustments
Finance functions can include trial balance, general-ledger statements, customer statements, revaluation, financial or business periods and controlled adjustments. Requirements vary, so the vendor should demonstrate the relevant scope rather than use broad labels.
Pay particular attention to corrections. Can a completed event be reversed through traceable entries, or is history edited? Are manual postings permission-controlled? Does the platform distinguish a business cancellation from an accounting correction? These details matter once the system contains real money and a real audit trail.
Evaluation principle: never accept “real-time ledger” as sufficient evidence. Ask for the complete posting chain for a payment, fee, FX conversion and provider reconciliation—including what happens when the external outcome differs from the expected outcome.
5. Payments, transfers and foreign exchange
Payments are workflows, not one feature. The platform may need to support internal transfers, domestic or international rails, outgoing and incoming transactions, own-account movements, beneficiaries, files or batches, fees, approvals, provider routing, statuses and returns.
Payment initiation and validation
An instruction should be validated against the configured product and account state. Checks may include user permission, account status, available funds, currency, amount limits, required fields, beneficiary rules, cut-off or scheduling logic and the need for another approval.
The exact legal and operational checks depend on the institution. The core must expose a controlled place to implement them and preserve the decision path. A customer-facing form that merely accepts data is not a complete payment capability.
Approval and signing workflows
Business propositions often need preparer-and-approver roles, several signatories or amount-based signature schemes. The platform should show who initiated an instruction, which approvals remain, whether the instruction changed after approval and when it became eligible for execution.
Authentication and signing requirements should be mapped to the applicable service and jurisdiction. For EU payment services, strong customer authentication and protection of personalised security credentials are governed by the relevant payment-services framework and its technical standards. Software can support the required mechanisms, but the regulated payment service provider remains responsible for the compliant implementation and use of exemptions.
Provider routing and transaction state
When an external provider executes the payment, the internal record should not jump from “submitted” to “complete” without explaining intermediate states. A useful model distinguishes accepted for processing, awaiting approval, sent, pending externally, completed, rejected, returned, cancelled or requiring investigation as appropriate to the rail and provider.
Status design is operational, not cosmetic. Each status should have a defined owner, allowed next actions, customer presentation and reconciliation consequence.
Incoming transactions and returns
Incoming payments require their own controls. The platform may receive provider messages or statements, identify the relevant customer account, apply configured fees or checks, create postings and route exceptions when the beneficiary or reference cannot be resolved.
Returns, recalls and rejected transactions should remain linked to the original instruction. Otherwise operations teams are forced to reconstruct the relationship manually.
Foreign exchange
FX functionality can include currency pairs, configured rates or provider quotes, spreads or fees, validity periods, exchange instructions, postings and resulting balances. Liquidity or execution may remain with an external provider.
Ask whether the platform records the customer rate, provider rate and any margin separately; how rate expiry is handled; which system owns the quote; and how an incomplete two-leg process is reconciled. “Multicurrency” and “FX” should not be treated as interchangeable labels.
6. Fees, tariffs, limits and product configuration
Fees and limits are how commercial policy becomes repeatable system behaviour. A platform should apply them consistently and retain enough version information to explain what happened at the time of a transaction.
Tariffs and fee rules
Useful tariff functions may include fixed and percentage fees, minimum or maximum values, currency, transaction type, customer or product applicability, tiers, schedules and effective dates. Some institutions need a standard tariff with negotiated customer overrides; others need several pricing packages.
The evaluation should test actual examples, including edge cases. What happens when the fee currency differs from the payment currency? When does a revised tariff become active? Can an operator waive or adjust a fee, and is the reason recorded? How is the fee posted and reported?
Transaction and account limits
Limits can apply per transaction, day, user, account, product, payment type or other defined scope. They may be hard controls, approval triggers or monitoring thresholds. The platform should make the semantics clear rather than presenting a generic “limit” field.
Limits also interact with channels and providers. A mobile app should not offer an amount the core will always reject, while a provider may impose a separate technical or programme limit. Procurement teams should map all three layers.
Product-rule governance
Configuration is powerful only when controlled. Ask which roles can create or approve product changes, whether four-eyes approval is available where required, how effective dating works and whether changes are recorded in audit history. A platform that is flexible but ungoverned can create as much operational risk as one that is inflexible.
7. Roles, permissions, approvals and audit history
Access control should reflect business responsibility. It must distinguish customers, customer representatives, operators, administrators, finance users, compliance staff and technical roles according to the institution’s operating model.
Role-based permissions
Role-based access should control both what a user can see and what the user can do. Sensitive actions—such as changing account status, amending product rules, approving a payment, making a manual posting or altering another user’s permissions—should not inherit broad access accidentally.
For corporate customers, the model may need organisation-level roles, account-specific rights and signing schemes. For internal staff, it may need separation by function, entity, branch or portfolio. Ask the vendor to demonstrate your most restrictive case, not only an administrator account.
Approvals and segregation of duties
Some actions require a second person or a different role. The platform should make approval state explicit, prevent the same user from bypassing the rule where segregation is required and preserve both the proposed and approved action.
Do not assume a “four-eyes” label covers every use case. Confirm which objects and actions can be configured for approval, what happens if the underlying data changes and how urgent exceptions are handled.
Audit and event history
Audit history should identify the actor, timestamp, action, relevant object and previous/new state where applicable. Technical logs are not a substitute for understandable business event history, though both can be important.
The institution should define retention, access and monitoring requirements. The platform should provide reliable evidence without claiming that logging alone satisfies every legal or supervisory obligation.
8. Cards and card-lifecycle management
Cards illustrate the difference between platform management and external processing. The core can maintain the customer’s card product relationship, expose lifecycle actions, record transactions and reconcile positions. An issuer, processor and scheme perform the external card functions defined by the programme.
A full card-management scope can include:
- physical and virtual card ordering;
- product and design selection;
- activation, block and unblock;
- closure, replacement and renewal;
- linking card accounts and customers;
- top-up or withdrawal movements where supported;
- viewing details and lifecycle status;
- transaction and authorisation history;
- synchronisation with the issuer or processor;
- statements, ledger reflection and reconciliation;
- back-office investigation and permitted manual actions.
Not every programme needs every function, and some actions may be performed directly in a processor platform. The important design decision is which system owns each lifecycle state and how discrepancies are resolved.
What to test in a card demonstration
Ask the vendor to follow one card from order to activation, a transaction, a temporary block, replacement and closure. Observe which events originate in the platform, which come from the processor and how the customer, operator, ledger and reconciliation views stay aligned.
Also test delayed or contradictory provider responses. The ideal path is not the difficult part. Operational quality appears when an action times out, a card status differs between systems or a transaction arrives after an account restriction.
For a deeper specialist treatment, use Advapay’s payment card issuing and card-management page.
9. KYC, KYB, AML and transaction-monitoring integrations
Core banking platforms commonly integrate KYC/KYB, screening, AML and transaction-monitoring services. The wording matters: integration is not the same as the core independently performing every verification or compliance decision.
Onboarding-provider integration
The platform can send customer or company data and documents to a selected provider, receive results, preserve references and statuses and route cases to operators. Different providers and jurisdictions require different fields and workflows.
The institution must define which outcomes can be accepted automatically, which require review and which evidence must be retained. A vendor should demonstrate the actual integration and exception workflow, not only show a provider logo.
Screening and monitoring
Sanctions, PEP, adverse-media or transaction-monitoring tools can generate alerts or results that require action. The operating platform should connect the result to the relevant customer, account or transaction and give authorised staff a controlled route to review, restrict, release or escalate according to policy.
The software should not market these integrations as a guarantee of compliance. Provider coverage, rule configuration, data quality, internal policy and human decisions all affect the outcome.
Provider portability
Because providers can change, evaluate whether the integration is isolated behind a defined adapter and whether customer and case history remains accessible if a provider is replaced. Portability is rarely effortless, but a clear boundary reduces the amount of business logic tied to one external API.
10. Reporting, back office and exception handling
Customer-facing features attract attention, but operational tooling determines whether the service can be run after launch. Every important transaction needs an operator view, permitted actions, evidence and a clear exception path.
Back-office workspaces
Operators may need to search customers, accounts, transactions, applications, documents, messages and provider references. Views should be role-appropriate: a support user does not need the same access as finance or an administrator.
The interface should explain state rather than merely expose database fields. For a payment, the operator should be able to see the instruction, approvals, validation outcome, provider messages, postings and current action without assembling the story across unrelated screens.
Queues and manual actions
Operational queues turn exceptions into assigned work. Examples include onboarding cases awaiting review, payments needing repair, unmatched reconciliation items, expired documents or customer service requests.
Manual actions should be limited, permission-controlled and recorded. The system should capture why an action was taken and, where required, who approved it. Direct database intervention is not an acceptable normal operating procedure.
Reports and exports
Reports may include customer and account lists, transaction registers, statements, trial balance, P&L, fee reports, reconciliation results and operational metrics. The exact reporting set depends on the institution and jurisdiction.
Ask which reports are native, which are configurable, which require a data warehouse or BI tool and how data is exported. “Reporting included” can mean anything from a few fixed PDFs to a governed analytical interface.
11. APIs, integrations and provider orchestration
Modern core banking software operates inside a wider ecosystem. APIs should expose controlled functions and data without forcing every integration to understand internal database structures.
API coverage and behaviour
API documentation should show authentication, permissions, request and response models, validation errors, idempotency or duplicate-handling where relevant, pagination, versioning and lifecycle status. A long endpoint list is less useful than a reliable production contract.
Ask to see how an instruction behaves when a network call is retried, a provider response is delayed or the same request is submitted twice. Financial APIs need explicit recovery semantics.
Integration adapters
An adapter translates between the platform’s controlled model and an external provider. It may handle credentials, field mapping, message formats, status mapping, retries and provider-specific references.
The existence of an adapter does not guarantee that it fits every client’s contract or product. Confirm version, supported services, geography, currencies, testing environment, operational monitoring and any implementation work still required.
Webhooks, events and scheduled processing
External systems may need event notifications, while the platform may need to receive asynchronous provider callbacks. Scheduled processes can handle statement import, reconciliation, reports, periodic fees, document checks or other background work.
Evaluate how failures are detected and replayed. A scheduler that silently stops or a webhook that cannot be traced can create operational gaps even when the primary API works correctly.
Partner and agent access
Some models expose controlled functions to partners or agents. This requires its own permissions, data scope, audit history and commercial boundaries. A partner API should not simply mirror administrator access.
12. Security, resilience and operational controls
Security is not one module and should not be reduced to an unverified certification claim. It emerges from identity and access design, authentication, encryption, secure development, infrastructure, monitoring, backup, recovery, incident handling, provider management and the institution’s operating procedures.
Authentication and access
The platform should support appropriate authentication for customers and staff, secure session handling, role-based permissions and the ability to revoke or restrict access. Payment initiation may require strong customer authentication or signing mechanisms depending on the service and jurisdiction.
Ask for evidence of how sensitive credentials are handled, how administrator access is controlled, how service accounts and APIs are authenticated and how access reviews are supported.
Availability, backup and recovery
Do not accept “cloud” or “on-premise” as a proxy for resilience. Request the proposed architecture, monitoring model, backup and restoration approach, recovery objectives, test evidence, incident responsibilities and third-party dependencies for the actual deployment.
EU financial entities should also evaluate ICT risk and third-party arrangements against applicable obligations such as the Digital Operational Resilience Act. DORA strengthens requirements around ICT risk management, incident handling, resilience testing and ICT third-party risk; a software feature list does not discharge the financial entity’s responsibilities.
Change and release control
The delivery model determines who operates infrastructure, deploys releases, tests changes and responds to incidents. SaaS, customer-controlled licence and source-code ownership allocate these responsibilities differently. This should be documented before selection rather than discovered during implementation.
For the deeper decision, see SaaS versus software licence and Advapay’s core banking security specialist.
13. Capability priorities by fintech model
The following matrix is a planning aid, not a legal-sufficiency checklist. “Core” means the capability normally matters to the proposition; “integrated” means a specialist provider or external system is typically part of delivery; and “model-dependent” means scope changes substantially with the product.
| Capability | EMI or payment institution | MSB or remittance | Neobank proposition | Crypto-fiat proposition |
|---|---|---|---|---|
| Customer, product and account records | Core | Core | Core | Core for fiat relationship |
| Double-entry ledger and GL | Core | Core | Core | Core across fiat and recorded crypto-related positions |
| Payment orchestration | Core for offered rails | Core for offered corridors | Core | Core for fiat legs |
| Fees, tariffs and limits | Core | Core | Core | Core |
| KYC/KYB, AML and screening | Integrated providers plus internal decisions | Integrated plus manual controls | Integrated plus internal decisions | Integrated KYC/KYB, AML and KYT where applicable |
| Card lifecycle management | Model-dependent | Optional | Commonly required | Optional |
| Reconciliation and reporting | Core | Core | Core | Core across all connected providers |
| Web and mobile channels | Usually required | Model-dependent | Usually required | Usually required |
| Crypto wallets and custody | Outside normal core scope | Optional | Optional | Core or integrated specialist module; custody model must be defined |
The matrix should be converted into an ownership map before procurement. For each capability, identify the system of record, external provider, operational owner, required evidence and fallback procedure.
14. How to evaluate core banking software
Vendor evaluation should turn marketing claims into observable evidence. A useful process begins with the operating model, follows representative journeys and tests exception handling—not only the ideal demo path.
Step 1: define the proposition and responsibilities
Document target markets, customer types, products, currencies, payment rails, card programme, banking access, verification providers, expected volumes, delivery model and internal teams. Identify what the regulated entity, sponsor or programme partner retains.
Without this context, vendors will demonstrate their standard scope and both sides may assume the missing responsibilities belong elsewhere.
Step 2: create end-to-end scenarios
Choose scenarios that cross modules. Examples:
- onboard a corporate customer with two authorised users;
- open EUR and GBP accounts and apply a tariff;
- create a SEPA payment that requires two approvals;
- process an incoming payment with an incomplete reference;
- perform an FX conversion and show both legs and postings;
- block and replace a card after a provider event;
- reconcile a provider statement containing one mismatch;
- change a product rule with approval and audit evidence.
Step 3: request evidence, not assurance
| Criterion | Evidence to request | Primary owner | Red flag |
|---|---|---|---|
| Business-model fit | Configured demo using your customer, product, currency, fee and restriction examples | Product and operations | Generic demo with no explanation of configuration limits |
| Ledger and accounting | Posting examples, chart-of-accounts mapping, period controls and reconciliation output | Finance and technology | Balances shown without traceable entries or correction handling |
| Operational tooling | Queues, audit history, permissions, manual actions, reports and exports | Operations and compliance | Every exception requires vendor or database intervention |
| APIs and integrations | Current documentation, error/retry behaviour, adapter scope, references and status mapping | Technology | “API-first” claim without production behaviour or ownership |
| Security and access | Authentication, role model, audit trail, vulnerability process and deployment-specific controls | Security and risk | Certification wording without scope, evidence or current applicability |
| Resilience | Architecture, monitoring, backup, recovery tests, incident process and service responsibilities | Technology and risk | Availability promise without recovery design or named owner |
| Migration | Data model, mapping, reconciliation, cutover, rollback and parallel-balance evidence | Technology and operations | Timeline excludes history, data quality and financial proof |
| Delivery capability | Named team, dependencies, governance, acceptance gates and relevant references | Programme owner | Fixed go-live promise before scope and providers are agreed |
| Support and roadmap | SLA, escalation, support hours, release notes, deprecation policy and roadmap governance | Operations and technology | Critical functionality exists only as an undated roadmap item |
Step 4: classify every gap
For each requirement, record whether it is available, configured, integrated, custom-developed or out of scope. Add the responsible party, dependency, acceptance evidence and estimated delivery stage.
This turns the selection document into the beginning of an implementation plan. It also prevents the word “customisable” from masking how much engineering and long-term maintenance the institution must own.
Step 5: evaluate the delivery model
SaaS can reduce the client’s infrastructure and release-management burden, but it leaves more operation with the vendor. A customer-controlled licence provides more environmental control while requiring infrastructure, security and deployment capability. Source-code ownership offers the greatest technical control and the greatest permanent engineering responsibility.
The correct option depends on the team, not prestige. A founder without a platform engineering organisation may gain little from owning code. A mature institution with strict deployment or modification needs may accept the additional responsibility.
Step 6: test implementation realism
A settled standard implementation may be planned around two to three months when scope, providers and responsibilities are clear. Complex migration, cards, crypto, mobile or new-integration programmes can require six months or more. These are planning ranges, not unconditional delivery promises.
Ask for dependencies and acceptance gates: product configuration, provider access, environment readiness, data mapping, integration tests, accounting proof, operational procedures, training, security review, reconciliation and go-live support.
15. Where Macrobank fits
Macrobank is Advapay’s modular core banking software for fintechs, payment institutions, electronic money institutions, PSPs, neobanks and related financial propositions. More than 50 PSPs actively use Macrobank. It can be delivered as vendor-operated SaaS, as software in a customer-controlled environment or with source-code ownership, depending on the agreed model.
Its controlled operating scope can include:
- private and corporate customer management, related persons and documents;
- product, account, IBAN and multicurrency structures;
- customer and general-ledger accounting, statements and reconciliation;
- internal, SEPA and international payment workflows, FX and provider integration;
- tariffs, fees, limits, permissions, signature schemes and approvals;
- web, mobile, operator, administration and partner interfaces;
- card-management and crypto-related modules where included in scope;
- APIs, background processing, reports, action history and operational tools;
- integration with banks, payment rails, card processors, verification/screening, FX/liquidity and other specialist providers.
Macrobank does not replace the client’s licence, policies, banking access, scheme relationships, external provider contracts or accountable decisions. Advapay’s delivery work is therefore based on the operating model: what the client is building, which providers are required, what the platform must control and who is responsible for each part after go-live.
What Advapay needs from the client
The client does not need high-end core-banking engineering expertise to begin. It does need to understand the business it intends to build, give clear and understandable requirements, make timely product and operating decisions, provide access and information for agreed providers and assign owners who can accept the configured result.
Advapay can support platform delivery, configuration and integration work within the agreed scope. Where relevant, the wider group can also help clients coordinate licensing, banking access, compliance operations and market-entry dependencies. These services should be scoped explicitly rather than assumed from the software licence.
Plan a relevant demonstration
A useful Macrobank demonstration should use the client’s proposition, not a generic tour. Share the target jurisdiction, customer types, currencies, payment rails, card or crypto requirements, preferred delivery model and existing providers. Advapay can then focus the walkthrough on the modules and responsibility boundaries that matter.
16. Frequently asked questions
What are the essential features of a core banking system?
The essential features normally include customer and product management, account and balance control, double-entry ledger and accounting, payments, fees and limits, roles and approvals, reporting, reconciliation, audit history, APIs and operational tooling. Cards, crypto, channels and specialist-provider integrations depend on the proposition.
What are the main modules in core banking software?
Common modules cover customers, products, accounts, ledger/accounting, payments and FX, tariffs and fees, cards, reports, user permissions, workflows, audit history, APIs and administration. Module names vary by vendor, so evaluate end-to-end behaviour rather than labels.
Does a core banking platform include KYC and AML?
It can integrate KYC/KYB, screening, AML and transaction-monitoring providers and preserve related statuses, references and workflows. The provider performs the contracted specialist service, while the institution remains responsible for policy, decision ownership and compliant operation. Avoid assuming a platform alone “makes” the business compliant.
Is card processing part of the core banking system?
The platform can manage the card product and lifecycle, customer relationship, internal records, statements and reconciliation. External issuer/processors and schemes normally perform issuance and real-time processing functions under the card programme. The ownership of each status and action must be defined.
What is the difference between a core banking module and an integration?
A module implements controlled platform capability, such as accounts, ledger or fees. An integration connects that capability to an external system or provider. Some services combine both: the core owns the internal payment record while an adapter sends the instruction to a bank or rail.
Should every fintech use the same feature checklist?
No. A checklist should be derived from the fintech’s customer types, licence or sponsor model, markets, products, currencies, payment rails, providers and operating responsibilities. A feature that is essential for a business neobank may be unnecessary for a narrow remittance proposition.
How should we compare core banking vendors?
Use configured demonstrations and end-to-end scenarios. Request posting evidence, permissions, provider boundaries, exception handling, reconciliation, API behaviour, resilience design, implementation dependencies and named ownership. Classify each requirement as available, configurable, integrated, custom-developed or out of scope.
How long does core banking implementation take?
A settled standard scope may be planned around two to three months. Complex migration, new integrations, cards, crypto, mobile or extensive customisation can require six months or more. The credible estimate follows agreed scope and dependencies; it should not be a fixed promise made before discovery.
Can a core banking platform guarantee compliance?
No. Software can support controls, evidence, workflows and integrations. Compliance also depends on the institution’s permissions, policies, configuration, data, people, providers, infrastructure and accountable decisions in the relevant jurisdiction.
What should we provide before a vendor demonstration?
Provide your target markets, customer types, products, currencies, payment rails, card or crypto scope, expected providers, delivery model, migration needs and target timeline. Add two or three realistic customer and operator journeys so the demonstration can test actual fit.
Final decision framework
The best core banking platform is not the one with the most boxes on a feature sheet. It is the one that can express the institution’s products, preserve an explainable financial record, coordinate the required providers and give authorised teams the controls and evidence to operate the service.
Start with responsibility and proof. Define what the core owns, what channels present, what providers execute and what the institution must decide. Then test the ledger, workflows, APIs, exceptions and reconciliation using your own scenarios. This approach produces a smaller and more accurate requirements list—and a far more reliable implementation plan.
