Introduction
Federation enables financial institutions to send push notifications to specific subsets of users through the nudge® platform. This can be used to communicate with specific account holders about refinancing high interest loans, activating new debit/credit cards, switching to eStatements and much more. By passing account holder identity through the nudge® library after authentication into the mobile banking application, the system is able to associate that identity with the push messaging token tied to that device. Later, the FI client can upload a list of ids in the nudge® portal to be used as a segment for subsequent messaging.
Options for the Federation Id
Key to implementing Federation is establishing the Id value (Federation Id) to use for the account holder identity. It needs to be something available within the mobile banking application that can be uniquely tied to the account holder to whom the device belongs. It also needs to be available within any query tool the FI uses to create their segmented lists. Here are some common examples:
- Email address
- Customer or member number
- Account number
- User Id
The email address option is very convenient for clients, and is recommended by Larky. It allows a client to use the same process and lists they already use for segmented email campaigns. With very little effort (likely none at all) they can reuse those lists and upload them directly to the nudge® portal and begin
Larky is happy to consult on the available options to determine which one would be best for a given FI client’s use-cases.
Implementing Federation in the nudge® Library
Federation is implemented as a parameter passed through the library initialization routine. For Android, use the setUserFederationId parameter in NudgeBuilder(). For iOS it’s the federationId parameter on the nudge class. In both cases this is a string variable. For full details, refer to our detailed integration guides, available here.
Architectural Implementation Options
There are two options for how to implement Federation. Each has its own advantages and disadvantages.
Single Initialization
This is the simpler option, but limits messaging options for the client. The NudgeBuilder() or nudge class initialization call is placed in the mobile banking application code shortly after authentication is completed, with the setUserFederationId or federationId parameter containing the appropriate FederationId value. This allows the segmented messaging.
Dual Initialization
A common architecture choice is to initialize the library early in the application startup process (pre-authentication) without the FederationId parameter, and then reinitialized post authentication with the parameter. This enables basic messaging to be performed regardless of the authentication state as well as targeted messaging post-authentication. It can also significantly simplify the testing process, as those performing testing don’t need sample account credentials.
Full Integration Documentation
Our complete integration documentation, which includes the Federation-specific details mentioned above, is available here.
We're here to help!
Have questions? Want to schedule time with our technical team to discuss implementation details. Just reach out to us through the Submit a request link above, or email us at support@larky.com.
Comments
0 comments
Please sign in to leave a comment.