← Domain guides

Change Account Name

Change Account’s Name Guide

Via the Banno/account-updates service, it’s possible to change the account’s name of a user.

Problems

Failing to Update Account Name for Banks NetTeller

Note - these instructions only apply to Banks, not Credit Unions.

When changing the account’s name for a NetTeller Retail User, the BSL call will fail if netteller-bsl-service does not include the Alias for the current value.

This problem has arisen more than once due to how, during the fetch, MDS collects the names associated with accounts. Per https://github.com/Banno/mobile-data-services/issues/4611, it will use the Product Description as the Account’s Name if the Alias is missing per this line of code.

Example: https://github.com/Banno/customer-issues/issues/5920

Kibana Queries

Step 1 - find error in account-updates service

To find an error associated with changing an account name, I suggest:

  1. Add a filter on app_name is account-updates
  2. Search for user id

Example output:

com.banno.account_updates.netteller.NetTeller$FailedToChangeAccountName:
 Failed to update Account Name for NetTellerId: 617900043158
 for Account Id: bde48dc0-33aa-11e9-9293-02428d048a18
 from present name: EZ CKG to new name: Plunder Acct (un-normalized)
 having Request Id: bfc037cf3ee536e45d6ac6c58e9c00ee

Caused by: org.http4s.client.UnexpectedStatus: unexpected HTTP status: 400 Bad Request

Step 2 - given the “Request Id” from Step 1, query BSL

Taking the above “Request Id” as an example, add it to the second search argument:

  1. Replace the app_name filter value with netteller-bsl-service
  2. Search for the request id from the previous output

Then, look at the HTTP Response from the BSL. Example:

BSL Integration
Request Id: bfc037cf3ee536e45d6ac6c58e9c00ee
Request: {
  "ActivityTracking" : {
    "ActivityId" : "311ef590-35eb-11e9-83fa-02429e84ea30"
  },
  "EndUser" : {
    "InternalId" : "617900043158",
    "InternalSecondaryId" : null,
    "UserType" : 1
  },
  "ApplicationNameType" : 2,
  "NewAccountDesignator" : "Plunder Acct",
  "InstitutionId" : "6179",
  "__type" : "UpdateAccountDesignatorRequest:#Jha.Account.Business.Entities",
  "PreviousAccountDesignator" : "EZ CKG"
}
URL: https://ntbsl.netteller.com:442/Jha.Account.WebHost/Account.V001.svc/rest/SaveAccount
Response Body: {
  "__type" : "UpdateAccountDesignatorResponse:#Jha.Account.Business.Entities",
  "BaseRequest" : {
    "Alias" : null,
    "ActivityTracking" : {
      "ActivityId" : "311ef590-35eb-11e9-83fa-02429e84ea30",
      "ParentActivityId" : null
    },
    "EndUser" : {
      "Alias" : null,
      "ExternalId" : null,
      "ExternalSecondaryId" : null,
      "InternalId" : "617900043158",
      "InternalSecondaryId" : null,
      "UserType" : 1
    },
    "RequestType" : null,
    "ApplicationNameType" : 2,
    "NewAccountDesignator" : "Plunder Acct",
    "InstitutionId" : "6179",
    "ClientIpAddress" : null,
    "__type" : "UpdateAccountDesignatorRequest:#Jha.Account.Business.Entities",
    "ProductInformation" : null,
    "PreviousAccountDesignator" : "EZ CKG",
    "SecondaryId" : null,
    "AuthenticationUser" : null
  },
  "ResponseDetailCollection" : [
    {
      "ResponseCode" : 1006,
      "ResponseMessage" : "The Account Designator was not updated from:[EZ CKG] to:[Plunder Acct]"
    }
  ],
  "Success" : false
}
Response Status: 200
Content Length (bytes): 805
Response Time (milliseconds): 309

Note the error message at the bottom:

    {
      "ResponseCode" : 1006,
      "ResponseMessage" : "The Account Designator was not updated from:[EZ CKG] to:[Plunder Acct]"
    }

Step 3 - given the “PreviousAccountDesignator” value, find out if it’s actually the Product Description

From Step 2, I’m using the “PreviousAccountDesignator” value of “EZ CKG”

  1. Replace the app_name filter value with core-fetch
  2. Search for "EZ CKG" AND "had an empty Alias"
If a result shows up in Kibana

Observe the following search result:

NetTellerId: 617910000414 had an empty Alias Account Name, so using the non-empty ProdDesc value: EZ CKG

As a result, we now know that the BSL call failed since Banno uses the Prod Desc, not the Alias, for this account’s name.

Underlying cause

This happens for customers who have accounts that aren’t fully tied to their NTID. When Banno is using jXchange to get entitlements the accounts get returned as though the user should have access, which is actually not correct. NetTeller online banking would not show these accounts. When we begin using the BSL method for NT entitlements, it’s correctly returning only the accounts that are fully tied to the NTID, hence the change to what the end user sees.

There seems to be at least a few different possible ways to get into this state, such as adding an account to a CIF in core but then never performing the manual NTID maintenance to “finish” tying the account to the NTID. There seems to be some accounts opened through Onboard that are in this state also, either because a setting wasn’t correct, or possibly some kind of bug. So far those teams haven’t pinned down an underlying cause, and so any FI’s who have examples where they think Onboard might be involved should share the details with that team.

To “fix” this for an individual user, the FI simply needs to pull up the NTID in core > Work with Accounts in the edit mode and enter through all the screens. That will perform the NTID maintenance needed to associate the eligible accounts to the NTID.

else

Open a customer issue with the above information and add a Team-Espresso label.