Process and system analysis
We learn the channels, systems, users and existing controls.
BANKING SOFTWARE DEVELOPMENT
We develop custom applications and integrations for digital channels, administration and banking processes. From the customer portal to approval workflows, we build solutions with controlled access and traceable actions.

Welcome, Arta Demo
Recent transactions
Mobile app
Service request
Replacement debit card · KS-2041
We will notify you when the request is completed.
SOFTWARE FOR FINANCIAL INSTITUTIONS
A banking interface is only one part of the service. Behind it sit verifications, authorisations, account systems, payments and processes that have to work together.
At ENOR, we design applications that connect to this environment and respect each system's responsibilities. We help the institution improve its digital channels and internal work, with defined features and technically assessed integrations.
Who exchanges what
Illustrative viewCustomerDigital channels
Requests, authorisations and documents
Click the same party again to return to the animation.
Click a party to see its responsibility. The arrows show the information exchanged.
CORE SOLUTIONS
Every project starts from the process you want to improve. Each card takes you to the matching explanation.
Accounts, transactions, payments and requests in one web interface.
See moreCore services on the phone, with notifications and device management.
See moreSeveral users, roles, limits and approvals for companies.
See moreNew features connected to the core systems.
See moreDocumented registration, with review and an institution decision.
See moreFrom application to review, contract and administration.
See moreProfiles, requests and meetings according to the team's authorisation.
See moreEvery action with a status, a history and duplicate protection.
See morePreparation, review and approval by several people.
See moreDocuments linked to the request, in every channel.
See moreAlerts that are reviewed, followed and documented.
See moreIndicators with period, source and update time.
See moreWe do not offer a ready-to-install banking platform. We build the defined features and connect them to the systems the institution uses.
INTERNET AND MOBILE BANKING
Features are defined per project and connected to the systems that hold the official data.
Every balance shows what it means

Current account · EUR
AL•• •••• •••• 4821
Open the explanation of each balance, search and filter transactions, or close a session under “Devices”.
When information is not live, the interface shows the update time and the source.
Phone biometrics are not a synonym for banking authorisation of every transaction; authorisation follows the bank's rules.
BUSINESS BANKING
The company decides who prepares, who approves and up to what amount, while the bank executes only what it is sent.
Illustrative example
Bulk payment · PG-118
PreparedRule: above €10,000, 2 approvers are required
Approvals: 0/2
Send the batch for review, approve it with two people and send it. Try changing an amount after approval.

The company's internal approval is distinct from financial execution at the bank.
If the action's details change, existing approvals are reassessed according to the rules.
CORE BANKING INTEGRATIONS
We build around existing systems without replacing them needlessly, and make it clear which system holds what.
We define the official source for
Channels
Integration layer
Existing systems
Official source for
Balances: the official source is Core banking. The channels read it through the integration layer and keep no copy that competes with it.
Pick a data type to see its official source. Simulate a core outage to see how the channels behave.
The application does not create an independent copy of the balance that competes with the official record. Compatibility with a core banking system depends on the product, version, interfaces, documentation and authorisations.
Building a new core banking system from scratch is treated as a separate programme, with its own analysis, controls and validation.
PAYMENTS AND TRANSFERS
The request, the authorisation and the result are stored separately, so the customer and the team see exactly where an action is.
Statuses that are never confused
Request key: 7f3c-91a2
Authorise and send the transfer. Try a timeout, a repeated send and changing the payee after authorisation.
A timeout is not proof that the transfer failed. Identifiers, idempotency and status checks prevent duplicate actions.
Integrations with payment schemes and message standards are assessed per market and provider. We do not promise instant global transfers.
ONBOARDING AND KYC
The form, documents, checks and decision are linked in a single case with a complete history.
Three different things
Individual customer · Elona Demo
Technical document verification
Technical checks by the verification provider.
Check results
Information for review, not a decision.
Institution decision
In manual reviewCase history
The decision to accept the customer is made by the institution, not by the API.
Pick a reason and make the decision. Without a reason, the decision is not saved.
An API result is not presented as a final legal or financial decision.
Collecting and storing documents is limited to the defined needs and requirements.
LOANS AND REQUESTS
Each stage has its owner, documents and status, and calculations follow the product approved by the institution.
Distinct stages
Indicative simulation
Not bindingWho acts: The customer, in the app
Illustrative rate of the Demo product: 7.5 %
Indicative instalment€193.43
Indicative simulation, not an offer. Final terms come after the bank's review.
Change the amount and term in the simulation, then step through the other stages to see what changes.
Calculations follow the product and terms approved by the institution; a simulation is not an offer.
We do not promise automatic approval or an infallible creditworthiness assessment.
BANKING CRM
Each role sees what it needs for its work, and marketing communications are kept apart from service notifications.
View as
Communication with the customer
Switch roles to see which fields open and which stay closed.

Access follows the needs of the job. We do not copy all financial data into the CRM without a defined purpose.
Marketing communications are kept distinct from service notifications.
OPEN BANKING AND APIs
Every access has a scope, an expiry and a way to revoke it, and every API has documentation, versions and limits.
Demo budgeting app
ActiveGranted on 02.05 · Expires on 31.07
Recent requests
Revoke the authorisation and look at the API responses. Under “API”, try the rate limit.
An internal API is distinct from a regulated Open Banking service. Legal references and standards are checked against current official sources before they are used.
We do not promise connections to every bank or access without the relevant authorisations.
OMNICHANNEL AND PROCESSES
A request keeps the same identifier and history, wherever it continues.
Examples
The same identifier and history in every channel
Go step by step and see the status update the same way in the app, the portal and for the team.

We keep the same process identifier and history in every integrated channel.
We do not promise that every action started in one channel continues automatically in every other channel without integration.
RISK AND CASE MONITORING
Every alert has an owner, evidence and a reasoned decision, so the case is followed through to the end.
Four levels that are not equated
No owner
Assign an owner, add evidence and move the case to suspicion. Closing or confirming requires a reason.

An alert is not presented as proof of fraud.
We do not promise to prevent every illegal transaction or fully automated regulatory reporting.
AI AND ANALYSIS
AI works with authorised sources and helps the team find, summarise and prepare information.
Controls we include
Pick a question above.
Pick a question and see where the assistant stops.
AI does not make transfers, change limits or approve loans without defined controls.
We do not promise investment advice or certain market forecasts.
REPORTS AND DATA
Every report shows its period, source and update time, and differences come up as cases for review.
Period: 06–12.05 · Source: request system · Updated: today 07:00
Operational report. Not a financial or regulatory report.
Switch the period and see how the source and update time change. “Reconciliation” shows the differences.
Operational reporting is distinct from financial and regulatory reporting.
Regulatory reports need specifications, mapping and verification with the institution; we do not promise them as automatic compliance.
SECURITY
Measures are defined per project and risk, from the user's sign-in to recovery.
Access and authorisation
Data and secrets
Verification and recovery
Changing the amount or the payee is handled under the re-authorisation rules.
We do not show sensitive data in logs, analytics or push notifications.
Blockchain is not a requirement for banking security.
INSTITUTION REQUIREMENTS
Requirements are identified at the start, together with the institution, and documented as part of the project scope.

During analysis we define
Not the same thing
GDPR
A European Union regulation on the protection of personal data.
Applicability depends on the jurisdiction and on local data laws.
PCI DSS
A card industry standard for protecting cardholder data.
Relevant where card data is stored, processed or transmitted.
ISO/IEC 27001
An international standard for information security management systems.
Organisations are certified, not a single application.
Every legal reference or standard is checked against the current official source before it is used in a project.
ENOR does not claim certifications, accreditations or universal compliance. Project requirements are verified with the institution.
RELIABILITY AND SCALING
Performance, availability and recovery objectives are defined with the institution and tested.
Switch the receiving system off and process the queue a few times, then bring it back. No message is processed twice.

We do not promise absolute uptime or millions of users without evidence.
Architecture is chosen per project. Microservices and Kubernetes are not a requirement for every system.
MODERNISATION AND MIGRATION
The move happens in phases, with a trial migration and reconciliation, so no financial action is duplicated.
We check
| Data | Old system | New system |
|---|---|---|
| Accounts | 18,240 | 18,240 |
| Transactions 2025 | 1,942,118 | 1,942,118 |
| Requests in progress | 312 | 309 |
3 requests in progress without a clear status → under review before cutover; not resent automatically
Rollback plan: ready
No financial action is duplicated during the cutover.
We do not promise zero-downtime migration without analysis.
DEVELOPMENT PROCESS
Deliverables, acceptance criteria and scope changes are documented throughout the project.
We learn the channels, systems, users and existing controls.
We define what is built, the risks and who is responsible for each system.
We design the integrations, roles and interfaces for customers and teams.
We build in phases, with regular demos.
We verify logic, authorisations, integrations and failure scenarios.
The institution accepts against the criteria and we start with a limited group.
We monitor, maintain and extend as agreed.
TESTING
Critical scenarios are tested against an expected result defined in advance.
Types of testing per project
WHY ENOR
Code ownership, licences, handover and recurring costs are set in the agreement.

FREQUENTLY ASKED QUESTIONS
More solutions for your business needs.
Building a digital financial product or a new service model?See FinTech Software Development
Tell us the objective, the users and the systems involved. We will define a concrete scope for analysis and development.
Sample Logistics Co.
“They translated complex technical concepts into clear decisions for our team.”