Your solution of an abstract `Account` class and an interface for the the `nonCD` accounts should work.

But it depends how you intend to use the class and the interface in your API. Do you for example assume that every time you have a `nonCD`, it’s necessarily an account? If yes, two alternatives are possible: 

* You could make `nonCD` an abstract class that extends `Account`.  This works well if the type of account is defined at construction and is not supposed to change. 
* You could use the [decorator pattern ][1]where `nonCD` would extend the responsibilities of `Account`. This works well if responsibilities of the account would change during its lifetime, and might be over-engineering in your case. 

***Not related**: The comments suggest that you are not in banking software but more in learning by simulating banking. This is why I’d like to question your understanding of the requirements. I’ve understood that a [CD account][2] is a deposit-only account. There is no withdrawal on it: withdrawal of money means to close that account. But perhaps these accounts work differently in the simulation world you're working on, and it’s OK for your exercise. So cross-check it before starting to build on the wrong assumptions*.

  [1]: https://en.m.wikipedia.org/wiki/Decorator_pattern
  [2]: https://bettermoneyhabits.bankofamerica.com/en/personal-banking/what-is-a-cd-investment