BANKING SOFTWARE DEVELOPMENT

Connect the customer experiencewith the bank's processes.

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.

Modern office building with a glass façade at dusk
Demo Bank · Internet bankingIllustrative view

Welcome, Arta Demo

  • Current account€3,930.40Available · AL•• 4821
  • Savings account€12,800.00Available · AL•• 9013

Recent transactions

  • Salary · Demo Company+€1,380.00
  • Rent payment−€450.00
  • Energy bill−€62.30
Awaiting approvalSupplier payment · €3,200 · 1 of 2 approvals

Mobile app

Service request

Replacement debit card · KS-2041

  1. Submitted
  2. Under review
  3. Completed
Submitted

We will notify you when the request is completed.

  • Digital channels
  • Integrations with banking systems
  • Controlled processes

SOFTWARE FOR FINANCIAL INSTITUTIONS

A simpler experience for the customer. Clearer control for the team.

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 view

CustomerDigital 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.

INTERNET AND MOBILE BANKING

Digital channels that make the service easier to reach.

Features are defined per project and connected to the systems that hold the official data.

  • Account overview
  • Balances
  • Transaction history
  • Search and filters
  • Statements and documents
  • Payees
  • Transfer requests
  • Payments
  • Notifications
  • Service requests
  • Device and session management

Every balance shows what it means

  1. 01Ledger balanceThe amount recorded after posted transactions.
  2. 02Held amountsAuthorisations or pending actions, where the system provides them.
  3. 03Available balanceThe amount that can be used now.
Employee using a phone in the office
Internet banking · Arta DemoIllustrative view

Current account · EUR

AL•• •••• •••• 4821

Ledger balance
€4,250.40
Held amounts
−€320.00
Available balance
€3,930.40
Updated 4 min ago · source: account system

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

Controls that follow how the company is organised.

The company decides who prepares, who approves and up to what amount, while the bank executes only what it is sent.

  • Several users per company
  • Roles
  • Authorised accounts
  • Action limits
  • Preparation and approval
  • Several approval levels
  • Single or bulk payments
  • File import
  • Reports and exports
  • Activity history

Illustrative example

  1. Prepared
  2. Under review
  3. Approved
  4. Sent
  5. Result confirmed
Business portal · Demo Company LtdIllustrative view
  1. Prepared
  2. Under review
  3. Approved
  4. Sent
  5. Result confirmed

Bulk payment · PG-118

Prepared

Rule: above €10,000, 2 approvers are required

  • Supplier Alpha€6,400.00
  • Supplier Beta€3,150.00
  • Demo IT Services€2,200.00
  • Total€11,750.00
  • ArtaPreparer · Finance
  • BesnikFinance director
  • EliraAdministrator

Approvals: 0/2

Send the batch for review, approve it with two people and send it. Try changing an amount after approval.

Business team meeting around a table

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

New features, connected to the core systems.

We build around existing systems without replacing them needlessly, and make it clear which system holds what.

  • Integration layers
  • APIs
  • Portals and applications
  • Internal processes
  • Data exchange
  • Integration monitoring
  • Gradual modernisation

We define the official source for

  • Accounts
  • Balances
  • Transactions
  • Products
  • Statuses
Integration with core systems · simplified viewIllustrative view

Channels

  • Internet banking
  • Mobile banking
  • Business portal
  • Staff app

Integration layer

  • API
  • Message queue
  • Monitoring

Existing systems

  • Core banking
  • Payment system
  • Document archive
  • CRM

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.

  • Core bankingActive
  • Payment systemActive
  • Document archiveDelayed

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

Every action with a clear status and history.

The request, the authorisation and the result are stored separately, so the customer and the team see exactly where an action is.

  • Payees
  • Data validation
  • Limits
  • Fees
  • Execution date
  • Scheduled actions
  • Authorisation
  • Submission to the relevant system
  • Confirmation
  • Rejection
  • Return or correction where supported

Statuses that are never confused

  1. 01Request createdSaved, not yet authorised.
  2. 02Request authorisedConfirmed by the customer or an allowed person.
  3. 03Accepted by the systemThe payment system received it.
  4. 04ProcessingThe action is under way.
  5. 05CompletedThe system confirmed the result.
  6. 06SettledWhere the payment scheme applies it.
Transfer · TRF-30418Illustrative view
Payee
Agim Demo · AL•• 7730
Amount
€1,250.00
Execution
Today
Fee
€2.00

Request key: 7f3c-91a2

  1. 1CreatedRequest saved
  2. 2AuthorisedThe customer authorised it
  3. 3AcceptedReceived by the payment system
  4. 4ProcessingBeing processed
  5. 5CompletedConfirmed by the system
  6. 6SettledWhere the scheme applies

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

An organised, documented registration process.

The form, documents, checks and decision are linked in a single case with a complete history.

  • Forms
  • Documents
  • Completeness checks
  • Identification integrations
  • Checks with specialised providers
  • Case management
  • Manual review
  • Decision
  • Reason
  • History
  • Data updates

Three different things

  1. 01Technical verificationWhether the document is readable and valid.
  2. 02Check resultWhat the provider or rule returned.
  3. 03Institution decisionAccepting the customer, with a reason.
Onboarding case · ON-2207Illustrative view

Individual customer · Elona Demo

Technical document verification

  • The document is readable
  • The expiry date is valid
  • The photo matches the selfie, per the provider

Technical checks by the verification provider.

Check results

  • Screening: 1 possible name match
  • Proof of address is missing

Information for review, not a decision.

Institution decision

In manual review

Case history

  1. The customer completed the form in the app
  2. The verification provider returned the technical results
  3. The case was assigned to Drita · Compliance

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

From application to review and administration.

Each stage has its owner, documents and status, and calculations follow the product approved by the institution.

  • Applications
  • Documents
  • Tasks
  • Verifications
  • Approval workflows
  • Offers
  • Contracts
  • Repayment plans
  • Notifications
  • Integrations with the relevant systems

Distinct stages

  1. Indicative simulation
  2. Offer
  3. Approval
  4. Contract
  5. Disbursement
Consumer loan · KR-7731Illustrative view

Indicative simulation

Not binding

Who acts: The customer, in the app

Term:

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

The right information for the authorised team.

Each role sees what it needs for its work, and marketing communications are kept apart from service notifications.

  • Customer profiles
  • Company relationships
  • Requests
  • Meetings
  • Tasks
  • Complaints
  • Sales opportunities
  • Communication history
  • Contact preferences
  • Documents by authorisation
Profile · Demo Company LtdIllustrative view

View as

Contact
Arta Demo · Finance director
Open requests
2 · KS-2041, KS-2055
Complaints
1 · in progress
Next meeting
Not needed for this role
Sales opportunity
Not needed for this role
Documents
Not needed for this role
Contact preferences
Email · working days

Communication with the customer

  • Service notificationsActive
  • Marketing communicationsNo consent

Switch roles to see which fields open and which stay closed.

Advisor meeting a client in an office

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

Controlled exchange with the financial ecosystem.

Every access has a scope, an expiry and a way to revoke it, and every API has documentation, versions and limits.

  • API design
  • Authentication and authorisation
  • Access scopes
  • Consents or authorisations by model
  • Expiry and revocation
  • Rate limiting
  • Versioning
  • Sandbox
  • Documentation
  • Monitoring
Authorisations and APIs · simplified viewIllustrative view

Demo budgeting app

Active

Granted on 02.05 · Expires on 31.07

  • Read accounts
  • Transactions from the last 90 days
  • Initiate payments

Recent requests

  • GET /accounts200
  • GET /transactions?days=90200
  • POST /payments403 · out of scope

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

Continuity between the app, the portal and the team.

A request keeps the same identifier and history, wherever it continues.

Examples

  • A request starts in the app and is reviewed by the team.
  • A document is completed through the portal.
  • A meeting is linked to the request.
  • The status updates in the relevant channels.
  • The customer receives a notification.
Process KR-55120 · business loanIllustrative view
  1. AppThe request starts in the mobile app
  2. TeamThe team reviews it and asks for financial statements
  3. PortalThe customer uploads the document in the business portal
  4. MeetingThe meeting with the manager is linked to the request
  5. NotificationThe customer is notified about the offer

The same identifier and history in every channel

  • AppKR-55120Submitted
  • PortalKR-55120Submitted
  • TeamKR-55120Submitted

Go step by step and see the status update the same way in the app, the portal and for the team.

Customer service team with headsets in an office

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

Alerts that can be reviewed and followed up.

Every alert has an owner, evidence and a reasoned decision, so the case is followed through to the end.

  • Rules
  • Integrations with existing engines
  • Alerts
  • Priority
  • Owner assignment
  • Evidence
  • Decisions
  • Reasons
  • History
  • Reporting

Four levels that are not equated

  1. 01AnomalyA deviation from usual behaviour.
  2. 02AlertFlagged for review by a rule or engine.
  3. 03SuspicionA documented reason to investigate.
  4. 04Confirmed caseA decision by the authorised person.
Case AL-8812Illustrative view
  1. AnomalyA deviation from usual behaviour
  2. AlertFlagged for review by a rule
  3. SuspicionA documented reason to investigate
  4. Confirmed caseDecision by the authorised person
Event
3 transfers to new payees within 40 min
Amount
€4,900
Source
Rule R-14 · existing engine
Priority
High

No owner

Assign an owner, add evidence and move the case to suspicion. Closing or confirming requires a reason.

Analysts working at monitors in an office

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 to support the work, within defined limits.

AI works with authorised sources and helps the team find, summarise and prepare information.

  • Documentation search
  • Request summaries
  • Document classification
  • Data extraction for verification
  • Drafting replies
  • Anomaly flagging
  • Operational analysis

Controls we include

  • Authorised sources
  • Access control
  • Quality measurement
  • Review
  • Monitoring
  • Action limits
AI Development
Team assistantIllustrative view

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

Reports with a clear source and meaning.

Every report shows its period, source and update time, and differences come up as cases for review.

  • Channel activity
  • Requests by status
  • Processing time
  • Failed actions
  • Transactions
  • Reconciliation
  • Team workload
  • Reports by role
Operational report · digital channelsIllustrative view

Period: 06–12.05 · Source: request system · Updated: today 07:00

  • New42
  • Under review31
  • Completed118
  • Rejected9
Average processing time
1.8 days
Failed actions
0.6%

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

Control at every step of an action.

Measures are defined per project and risk, from the user's sign-in to recovery.

Access and authorisation

  • Least privilege
  • Appropriate authentication
  • Transaction authorisation
  • Separation of duties
  • Approval by several people when required
  • Session and device management

Data and secrets

  • Encryption
  • Key and secret management
  • Rate limiting
  • Audit logs

Verification and recovery

  • Threat modelling
  • Security testing
  • Monitoring 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

Built to the requirements of the bank and the market it operates in.

Requirements are identified at the start, together with the institution, and documented as part of the project scope.

Reception lobby with marble and plants

During analysis we define

  • Jurisdiction
  • The parties' roles
  • The data
  • Retention
  • Providers
  • Processing location
  • Audit requirements
  • Continuity
  • Contractual controls

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

Prepared for load and recovery.

Performance, availability and recovery objectives are defined with the institution and tested.

  • Defined performance objectives
  • Load testing
  • Concurrency handling
  • Processing queues
  • Idempotency
  • Controlled retries
  • Monitoring
  • Reconciliation
  • Backups
  • Restore tests
  • Incident response plan
Processing queue · simplified viewIllustrative view
  • MSG-901 · TRF-30501Queued
  • MSG-902 · TRF-30502Queued
  • MSG-903 · KS-2061Queued
  • MSG-904 · TRF-30503Queued
Recovery time objective (RTO)
Set with the institution and tested
Recovery point objective (RPO)
Set 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.

Server rack with network cables

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

Improve features while keeping control of the history.

The move happens in phases, with a trial migration and reconciliation, so no financial action is duplicated.

  • Audit
  • System mapping
  • Official data sources
  • Gradual integrations
  • Trial migration
  • Reconciliation
  • Pilot
  • Controlled cutover
  • Rollback plan

We check

  • References
  • Accounts
  • Balances
  • Transactions
  • Authorisations
  • Documents
  • Requests in progress
Trial migration checkIllustrative view
  1. 01Audit
  2. 02System mapping
  3. 03Official sources
  4. 04Trial migration
  5. 05Reconciliation
  6. 06Pilot
  7. 07Controlled cutover
DataOld systemNew system
Accounts18,24018,240
Transactions 20251,942,1181,942,118
Requests in progress312309

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

From the institution's requirementsto a verified solution.

Deliverables, acceptance criteria and scope changes are documented throughout the project.

01

Process and system analysis

We learn the channels, systems, users and existing controls.

02

Scope, risk and responsibilities

We define what is built, the risks and who is responsible for each system.

03

Architecture and UX/UI

We design the integrations, roles and interfaces for customers and teams.

04

Phased development

We build in phases, with regular demos.

05

Integration and testing

We verify logic, authorisations, integrations and failure scenarios.

06

Acceptance and pilot

The institution accepts against the criteria and we start with a limited group.

07

Release and maintenance

We monitor, maintain and extend as agreed.

Which banking process would you like to improve first?

Talk to ENOR
The timeline is set after analysis and also depends on access, approvals and third-party systems.

TESTING

We test the logic and the authorisations, not just the screens.

Critical scenarios are tested against an expected result defined in advance.

  • 01A repeated transfer request.Expected result: Recognised by the request key; only one transfer is created.
  • 02A timeout after sending.Expected result: The status is marked unknown and checked; the request is not blindly resent.
  • 03A late confirmation.Expected result: The status updates when the confirmation arrives and the customer is notified once.
  • 04Amount or currency mismatch.Expected result: The request stops before sending, with a clear message.
  • 05Payee changed after approval.Expected result: Approvals are cancelled and a new authorisation is required.
  • 06Unauthorised user.Expected result: The server rejects the action and the attempt is logged.
  • 07Bulk payment with partial results.Expected result: Each payment has its own status; rejected ones stay for correction.
  • 08Expired session.Expected result: The action stops and a new sign-in is required before any authorisation.
  • 09Stale cached data.Expected result: Shown with its update time and not used for decisions that need current data.
  • 10Reconciliation with differences.Expected result: Differences are listed with a reference and passed for review.
  • 11Restore from backup.Expected result: Data is restored within the tested objectives and checked by reconciliation.
  • Types of testing per project

    • Functional testing
    • Security testing
    • Integration testing
    • Performance testing

WHY ENOR

A development partner for processes that demand accuracy.

  • Clear scope and responsibilitiesEvery feature and every system has a defined owner.
  • Documented integrationsRules, errors and reconciliation described for every connection.
  • Role-based interfacesFor customers, operations teams and administrators.
  • Traceable actionsWho did what and when, for every important action.
  • Testing of critical scenariosDuplicates, delays, authorisations and restores.
  • Maintenance and further developmentUpdates and extensions as agreed.

Code ownership, licences, handover and recurring costs are set in the agreement.

Professionals in a work meeting

FREQUENTLY ASKED QUESTIONS

Frequently asked questions.

Which banking process would you like to improve?

Tell us the objective, the users and the systems involved. We will define a concrete scope for analysis and development.


Describe the process; do not include customer, account or card data or any credentials.

What our clients say

5.0
A
Arben Hoxha, CEO

Sample Logistics Co.

“They translated complex technical concepts into clear decisions for our team.”