Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Epic] Provide filing details #150

Open
4 of 15 tasks
Tracked by #93
angelcardoz opened this issue Feb 26, 2024 · 6 comments
Open
4 of 15 tasks
Tracked by #93

[Epic] Provide filing details #150

angelcardoz opened this issue Feb 26, 2024 · 6 comments
Labels

Comments

@angelcardoz
Copy link
Contributor

angelcardoz commented Feb 26, 2024

Milestone:

Epic: Provide filing details

Overview

  • In this step a filer is asked to provide information that is specific to the current filing
    • Voluntary reporter status
    • Filing point of contact information
  • The information provided on this page meets the following criteria:
    • Is always user supplied
    • Is requested for every filing
    • Does not live in the financial institution profile

Small business lending rule

Voluntary reporter status

Regulation B requires financial institutions to report whether they are voluntarily reporting covered applications from small businesses. According to the official interpretation of Paragraph 109(b)(10), a financial institution that is not a covered financial institution but that elects to voluntary compile, maintain, and report data complies with § 1002.109(b)(10) by selecting “voluntary reporter.”

Point of contact information

Regulations B requires financial institutions to report the name and business contact information of a person who may be contacted with questions about the financial institution’s submission: § 1002.109(b)(1)(iii) https://www.consumerfinance.gov/rules-policy/regulations/1002/109/#a-3

"The name and business contact information of a person that the Bureau or other regulators may contact about the financial institution’s submission."

Tasks

Use the following checklist to ensure each epic is built out properly. If needed, you can add or remove items.

  • Pull together initial list of relevant user stories for this epic
  • Make a list of the content requirements for this epic
  • Make a list of the technical requirements for this epic
  • Post current wireframes and mock-ups
  • Review wireframes and mock-ups with FEWD, BEWD, Data, SBL Help, Content team members
  • Refine user stories to prepare for development phase
  • Identify and capture tasks for user testing
  • Conduct user testing

User stories

MVP (release date: 12/31/2024)

Backlog:

Beta release (8/1/2024)

Backlog (post-MVP)

  • Story (link)

User testing

Research goals

  • Determine what information filers need to provide a POC for the filing.
  • Determine what additional information we can provide to help filers provide a POC.
  • Learn how often filers expect the POC to change.
  • Understand how easily filers can determine whether their institution is a voluntary reporter.

Task ideation

  • Complete the POC fields.
  • Make the appropriate selection for the voluntary reporter section

Curent mock-ups

Updated:

@natalia-fitzgerald
Copy link
Contributor

natalia-fitzgerald commented Feb 26, 2024

@nongarak @Kibrael
I would like to clarify a few things as we move forward with this epic.

From what I've seen, SBL is pretty vague about what specific fields we should collect for point of contact. HMDA is more specific. HMDA includes a detailed list with guidelines in the filing instructions guide. Do we plan to add this level of detail to the small business lending filing instructions guide? Should we request the business contact phone number?

Here's the latest mock-up (updated to include HMDA fields): Epic: Point of contact (current mock-up)

@nongarak
Copy link

I just confirmed with Tim Lambert of OFLEO, and pending any revisions from someone else in the office who is on vacation, the fields that we should capture are the same as HMDA. Name, email, phone, and business address.

@nongarak
Copy link

I don't know what validations are in place for HMDA on phone number, but if it's possible to standardize phone number input in the field that would be a good thing probably. Like, 10 digits only, or requiring +1, or +1 (xxx) xxx-xxxx, or whatever other standard we want. I don't care, but probably locking it down is good. Especially so folks don't put in "nunya" or something.

@natalia-fitzgerald
Copy link
Contributor

natalia-fitzgerald commented Feb 28, 2024

@nongarak
Here's what I pulled from HMDA (filing instructions guide):

"Enter the name, telephone number, e-mail address, and office address of a person who may be contacted with questions about your institution's submission."

Enter the contact person's:

  1. Name
  2. Telephone Number
  3. E-mail Address
  4. Address
    a. Street Address 
    b. City
    c. State
    d. ZIP Code

Formatting specifications

  1. Full Name as (1) data field
  2. Telephone Number (Format: 999-999-9999)
  3. E-mail Address
  4. Address
    a. Street Address as (1) data field 
    b. City as (1) data field
    c. State (two-letter state code as (1) data field 
    (aa) State means any state, the District of Columbia, the Commonwealth of Puerto Rico, or any territory or possession of the United States.
    d. ZIP Code as (1) data field 

@billhimmelsbach - What other field formatting can we do for these types of fields? We can provide formatting examples in the fields but I'd like to identify what's possible for the front end to do as well. If we want the full name to ultimately be one data field do we have to only show one text input field "Full name" or can we show "First name" and "Last name" and have these be merged as one data field on our end? Preference?

@nongarak

  • HMDA says that phone number should be formatted as follows: 999-999-9999. Is this what we want to use for SBL?
  • What US territories should be included, in addition to the states?

HMDA:

https://ffiec.cfpb.gov/documentation/fig/2023/overview#1-5-to-1-11-paragraph-5a3iiicontact-person

Enter the name, telephone number, e-mail address, and office address of a person who may be contacted with questions about your institution's submission.

@hkeeler
Copy link
Member

hkeeler commented Feb 29, 2024

As for the State field, I'm guessing we'd want to go with the same values we allow for institution records. On cfpb/regtech-user-fi-management#48 (comment) we said...

Values here should be pretty self-explanatory. All 50 states and D.C. and territories...

code name
AS American Samoa
DC District of Columbia
GU Guam
MP Northern Mariana Islands
PR Puerto Rico
UM United States Minor Outlying Islands
VI Virgin Islands, U.S.

...assuming we're going with ISO-3166.

Pretty sure we decided to go with that.

@natalia-fitzgerald
Copy link
Contributor

natalia-fitzgerald commented Mar 7, 2024

Items to explore/track down

(Notes from DSR/SBL frontend meeting on 3/7/2024)

  • Should we include an urbanization field to account for Puerto Rico? USWDS includes this as a separate field with "Urbanization" label. USPS docs on it: https://pe.usps.com/text/pub28/28c2_042.htm
  • Should the state picker show a default? If so what should it be?
    • I will audit cf.gov and review best practices and CFPB Design System standards.
  • Should we change the state picker label to "State or territory"?
    • Is there any reason we wouldn't want to do this? If not, I added it to the mock-up.
  • Which fields would benefit from formatting examples?
    • I will explore this
  • Add real content for introduction text
  • Zip codes: Do we want to support a 5 digit zip code or Zip+4 (9 digit zip code)
    20002 vs 20002-3457 On the frontend we could support either or both, but what do we want to tell the user?

Notes:

  • List of states and territories should get pulled from the backend
  • We're sticking with the phone number format XXX-XXX-XXXX for now
  • We're going to only have 2 address lines for now, and see if users want more

USWDS recommendations: https://designsystem.digital.gov/patterns/create-a-user-profile/address/

  • Provide rich information cues in dropdowns. For example, for state dropdowns, use MD - Maryland and TX - Texas, rather than the state code alone
  • Do provide the Puerto Rican Urbanization field, unless your program does not serve Puerto Rico.
  • Avoid dropdowns that require long scrolling. If possible, let users type their state or territories’ abbreviation when they reach the state dropdown menu, instead of having to scroll and select. (USWDS uses the Combo box component: https://designsystem.digital.gov/components/combo-box/)
    • We will use the standard Select for MVP. We can consider the Combo box for post-MVP

@billhimmelsbach @hkeeler - Please edit as needed for accuracy or additional context.

@angelcardoz angelcardoz changed the title [Epic] Provide point of contact [Epic] Provide voluntary reporter status and point of contact Sep 25, 2024
@angelcardoz angelcardoz changed the title [Epic] Provide voluntary reporter status and point of contact [Epic] Indicate voluntary reporter status and provide point of contact Sep 25, 2024
@angelcardoz angelcardoz changed the title [Epic] Indicate voluntary reporter status and provide point of contact [Epic] Provide filing details Sep 26, 2024
@natalia-fitzgerald natalia-fitzgerald removed this from the 7. Sign and submit milestone Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants