Skip to content
IdentitéTrust starts here
English
EnglishEspañolPortuguês
Contact

Solutions / Financial services

Your bank knows its customer. Can your customer recognize your request?

A business-banking payment request should be more than a familiar screen and an approval button. Explore how a connected banking application can request deliberate customer confirmation through NoPass™ and use that response in its transaction policy.

A bank adviser and customer reviewing a transfer inside a bank branch
Your bank. Your decision.

A familiar-looking portal can ask for the wrong trust.

A customer arrives through a message or opens a page that looks like their bank. Before entering an account or approving an operation, they need more than visual familiarity with the brand.

In the FDA app-based relationship, the enrolled app verifies the authentication server connected to the service. The customer checks the comparison shown in the banking system and on their device before deciding.

The bank can authenticate the customer while giving that customer an active role in recognizing its request.

Ask before the transaction proceeds.

A banking application can hold a sensitive transaction and initiate a NoPass approval request. The customer receives the request on their phone and confirms on that device. The application uses the result before continuing.

This makes the customer’s decision part of the transaction workflow, beyond the earlier account sign-in.

Transaction approval · interactive example

A sensitive operation is ready.

The application sends a NoPass approval request to the person responsible. Start the request in the application.

Your bank
Example application request

Supplier payment

Recipient
Example supplier
Amount
USD 1,250.00
Reference
PAY-1042
NoPass
Enrolled deviceReady when you are.

Try the highlighted button or use the controls below.

Define the payment checkpoint.

The application owns what happens next.

NoPass supplies the authentication or approval result. The connected application owns permissions, the held operation and its execution policy.

  1. Prepared

    The application defines the action and responsible person.

  2. Waiting

    The application holds the action while requesting a decision.

  3. Decision

    The person accepts or declines using the configured experience.

  4. Application policy

    Approval is an input to the decision to proceed, not a replacement for business permissions.

Approved

Apply permissions and execution policy.

Not approved

Keep the action from proceeding.

Expired / no response

End or defer the request according to application policy.

Define the payment checkpoint.
Implementation questionOwner
Which payment state is held, and who may release it?Banking application team
How is the responsible customer enrolled and recovered?Identity and support teams
What happens after rejection, timeout or a changed payment?Application and security teams

Evaluate one business-banking workflow.

Define a useful decision before planning a wider rollout. Agree scope, responsibilities and success criteria with the team.

  1. Choose one workflow

    Identify the people, application and access or approval moment.

  2. Agree the integration

    Map enrollment, account ownership, result handling and recovery.

  3. Evaluate with representative users

    Observe completion, recovery and support workload against agreed criteria.

  4. Decide on rollout

    Use the findings to decide what to change, expand or stop.

Review a payment-approval workflow