Frequently Asked Questions

Bansoft is a configurable core banking platform delivered as a managed hosted service for regulated financial institutions. It brings customer records, accounts, transactions, reporting, and administrator controls together with dedicated hosting and ongoing technical operations.

Bansoft is provided under a recurring managed platform service fee. The annual platform service framework and billing schedule are confirmed in the applicable commercial agreement.

The current Bansoft model is not positioned as a one-time purchase followed by separate maintenance. Platform access and managed operations are provided during the active recurring service term.

Bansoft can share characteristics with hosted software services, but the more accurate public description is a managed hosted banking platform service because the model includes dedicated deployment, managed operations, maintenance, monitoring, backups, and institution-specific scope.

Pricing is provided for your requirements rather than through a fixed public price list. Deployment, configuration, integrations, hosting, and support needs determine the proposal.

The documented baseline includes platform access during the service term, dedicated hosted deployment, managed hosting operations, standard platform maintenance, code and interface support, security updates, monitoring, patching, backups, and standard technical support.

Third-party financial services, payment rails, custom integrations, extensive customization, expanded implementation services, migration, additional environments, and other client-specific requirements may require separate scope.

No universal SLA, 24/7 commitment, dedicated manager, or response time should be assumed. Any such commitments must be stated in the applicable agreement.

The client institution remains responsible for its business operations, policies, approvals, regulatory obligations, compliance program, and authorized use of the platform.

Yes. The Bansoft evaluation process is designed to support cross-functional review of scope, responsibilities, hosting, security, support, and commercial terms.

The platform includes documented multi-currency capabilities. Active currencies, account types, fees, reporting behavior, and foreign-exchange workflows are configured according to scope.

The documented platform uses UTF-8 data handling and supports configurable language and regional settings. The languages available in a deployment must be confirmed.

Administrators can configure account types and currencies. Documentation describes savings, current, term, loan, overdraft, Nostro, and optional card-account contexts, subject to enabled modules and configuration.

Yes. A Master Administrator can define administrator classes, permissions, and access to selected profile groups so operational responsibilities can be delegated.

Depending on enabled scope, users can view accounts and balances, review transactions, send messages, request transfers, generate reports, update permitted profile information, and upload documents.

Administrators can review requests, manage profiles and accounts, process transactions, generate reports, review logs, configure settings, manage fees, and control roles and workflows according to permissions.

Documentation describes account statements, transaction reports, user and global reports, audit records, and export options. Available reports depend on configuration.

Yes. The documented platform includes secure messaging between users and administrators, system-generated notifications, and institutional announcements.

Logos, colors, wording, report headers, email templates, and selected interface settings can be configured according to the agreed deployment.

The responsive browser interface can be evaluated for deployment as a WebView application. App-store packaging, assets, privacy links, support links, and publishing requirements require separate preparation.

Documentation describes authenticator-app, email, and SMS-based multi-factor and one-time-password options. Available channels depend on configuration and third-party provider setup.

Yes. Transaction-level OTP and security-key options can be configured for selected operations.

Administrators can configure password length, complexity, expiration, temporary-password behavior, and login-attempt limits.

Device authentication is documented for users and can be configured with expiration and OTP delivery options.

The platform documents IP allowlisting, blocklisting, administrator restrictions, and rate-limiting controls. Rules must be planned carefully to avoid blocking trusted access.

Yes. Concurrent-session restrictions and inactivity timeouts can be configured.

System logs and audit trails can record user, administrator, transaction, profile, account, security, document, and API activity according to the implemented configuration.

Document access can be governed through administrator classes, user groups, permissions, and audit records. Storage and encryption controls depend on the agreed environment.

Bansoft provides configurable controls and auditability to support your compliance program; it does not confer regulatory approval or automatic compliance. Your institution remains responsible for its obligations.

No. Cloud-provider attestations can support due diligence, but workload configuration, application controls, policies, operations, and institutional responsibilities remain part of the compliance assessment.

The documented service model uses a dedicated hosted environment. The exact hosting architecture, region, capacity, and resilience profile are confirmed by scope.

Managed operations can include monitoring, patching, backups, platform maintenance, security updates, and standard technical support within the agreed service boundaries.

Bansoft documentation describes AWS-based hosting profiles using EC2 and relational database services. The production hosting profile for a specific client must be confirmed.

Backups are part of the documented managed-service concept. Retention, frequency, encryption, restoration testing, and recovery objectives are deployment-specific.

No universal uptime guarantee is stated. Availability depends on the selected architecture and the commitments in the applicable agreement.

Documentation describes profiles ranging from single-node deployments to separated tiers and higher-availability designs. The appropriate model depends on requirements and budget.

Managed hosting profiles can include DDoS mitigation, web-application firewall rules, bot controls, rate limiting, TLS, and origin protection. Exact controls depend on the environment.

Administrative access can be controlled through application permissions, IP restrictions, MFA, and infrastructure access policies according to the deployment design.

Yes. Documentation describes a SOAP-based web services API using XML over HTTPS.

The integration model covers user, account, transaction, transfer, document, and compliance-related functions. Request the current method list and enabled scope during technical review.

API access can use unique keys, IP restrictions, method-level permissions, administrator-role boundaries, TLS, validation, and audit logging.

The documented integration interface uses SOAP web services with XML over HTTPS. If you require REST, discuss the requirement during technical review; REST availability is not included in the published interface description.

Approved API methods can support user-profile and account creation, subject to enabled methods, required data, permissions, validation, and institutional workflows.

Bansoft is integration-friendly, but each provider, method, workflow, contract, and compliance dependency must be evaluated and scoped separately.

Sandbox or development environments may be provided for testing, training, and integration activities according to the agreed evaluation or implementation scope.

Documentation refers to eventing and webhook options in selected integration flows. Availability and implementation details must be confirmed for the specific scope.

No universal public timeline is stated. Duration depends on configuration, integrations, migration, testing, approvals, training, infrastructure, and third-party readiness.

Provide institution type, jurisdictions, users, accounts, currencies, transaction types, controls, reporting, integrations, migration, hosting, security, support, and timeline requirements.

Data migration should be treated as a separate requirement unless it is expressly included in the proposal and implementation scope.

Branding, configuration, workflows, reports, and selected functions can be adapted within documented capabilities. Extensive customization requires separate review and scope.

A demo can be requested. Shared demonstrations should use test data only and must not contain personal, confidential, or production information.

Production readiness includes validated configuration, data, integrations, controls, testing, approvals, operational procedures, authorized users, support arrangements, and hosting readiness.

No. Regulatory approval and licensing remain the responsibility of the institution and its advisers.

Identify providers, contracts, credentials, data flows, fees, testing, support, security responsibilities, failure handling, and regulatory requirements before implementation.

Depending on the review, materials may include platform capability summaries, architecture, security, hosting, API, implementation, commercial scope, interface guidance, and responsibility boundaries.

Use the contact form to describe your institution and requirements, request a demo, or ask for a scope-led platform and service discussion.